FOREWORD 


By  Memorandum  dated  August  17 ,  1977,  the  Deputy  Assistant  Secre¬ 
tary  of  Defense  (Supply,  Maintenance  and  Services)  established 
a  Departaent  of  Defense  Study  to  conduct  a  coaprehenslve  review 
and  analysis  of  the  supply  support  request  (SSR)  systeas  for 
generating,  transalttlng,  processing  and  controlling  SSRs  In 
order  to  develop  systeas  laproveaents  to  proaote  effective  supply 
support  of  DoD  equipments* 


The  Study  included  a  review  of  SSR  policy  and  procedures,  the 
design  of  automated  systeas  to  lapleaent  the  procedures  and  an 
operational  lapleaentation  review  of  the  effectiveness  of  SSR 
systeas  design. 


This  Report  documents  the  study  approach  and  aethodology  used  in 
the  pursuit  of  the  study  and  presents  observations,  analyses, 
findings,  conclusions  and  recommendations  with  supporting  re¬ 
search  and  rationale. 


Anelysls  Office 
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CHAPTER  I 


QUANTITATIVE  EVALUATION 


A.  INTRODUCTION 

1 .  Background 

It  was  alleged  by  the  Special  Projects  Group  (SPG)  that 
Supply  Support  Requests  (SSRs)  were  not  being  processed  In  a 
timely  manner  due  to  an  excessive  reject  rate,  extended  trans¬ 
mission  times,  a  high  delinquency  rate  and  inadequate  controls. 

The  SPG  had  requested  the  Components  to  provide  statistical 
information  on  the  processing  of  SSRs.  The  information  provided 
by  the  Components  was  limited  and  not  sufficient  to  permit  an 
analysis  or  comparison. 

The  study  team  performed  a  review  of  the  management  re¬ 
ports  available  at  headquarters,  systems  design  and  operational 
activities  of  the  Components.  The  team  confirmed  the  SPG  finding 
that  there  was  very  little  management  data  available  on  SSRs  at 
any  level  and  that  available  information  was  not  adequate  to  per¬ 
form  a  quantitative  evaluation  of  the  performance  of  the  SSR 
Systems . 

The  study  group  discussed  the  lack  of  availability  of 
management  reports  with  the  chairman  and  members  of  the  SPG. 

The  study  group  expressed  their  desire  to  perform  a  quantitative 
evaluation  of  the  SSR  System  and  requested  approval  of  a  plan  to 
collect  and  analyze  SSR  transactions.  Authority  was  granted  to 
the  study  team  to  prepare  an  evaluation  plan  and  to  establish  a 
data  collection  and  analysis  system.  An  evaluation  plan  was 
developed,  data  collected  and  analyzed.  A  description  of  this 
process  and  presentation  of  the  results  are  contained  in  this 
Chapter . 

2.  Purpose .  The  purpose  of  the  evaluation  was  to  apply 
quantitative  methods  to  the  evaluation  of  the  supply  support  re¬ 
quest  systems  and  procedures  in  order  to  determine  the  relative 

e f f ec t i veness /e f f ic iency  of  Service /Agency  systems  and  procedures 
that  were  developed  to  implement  DoD  4140. 26M,  Volume  1,  May  1978. 

3.  Problem  Objective.  To  measure  the  performance  of  the 
respective  SSR  systems,  in  support  of  the  study  objectives  as 
stated  in  the  Study  Plan. 

4.  Scope .  Data  was  collected  on  all  known  methods  of  re¬ 
questing  and  obtaining  supply  support.  The  principal  SSR  Methods 
are  shown  below: 
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a.  Supply  Support  Requests  (SSRs). 

b.  Item  Management  Coding  (IMC). 

c.  User  Interest  Registration  (Add  User)* 

d.  Special  Program  Requirements  (SPR). 

e.  Nonconsumable  Item  Materiel  Support  Request  (NIMSR). 

5.  Approach.  A  quantitative  Evaluation  Plan  (Appendix  G) 
was  developed  to  direct  and  control  this  research.  The  major 
thrust  of  the  plan  was  to  analyze  the  problems  and  accomplish  the 
objectives  outlined  in  the  study  plan.  Research  was  accomplished 
in  accordance  with  the  plan  as  outlined  below: 

a.  The  major  submitters  (SICCs)  and  receivers  (IMMs)  of 
SSKs  were  identified. 

b.  A  reports  control  symbol  was  obtained  and  a  data 
collection  system  was  established. 

c.  Actual  transaction  data  was  collected  from  each  SSR 
submitter  and  receiver  for  a  specified  period  of  time. 

d.  Statistical  information  was  collected  from  selected 
activities  where  transaction  data  was  not  available  or  not 
feasible  to  collect. 


e . 

process i ng 

A  data  base  was  established  to  permit  computerized 
of  data. 

f  . 

process  . 

The 

data  base  was  purified  through  a  validation 

g* 

analysis  of 

Eva 

the 

luation  criteria  was  developed  to  be  used  in  the 
collected  data. 

(1) 

Goals . 

(2) 

Standards . 

(3) 

Times . 

(M 

Reject  Rates. 

(5) 

Transaction  Patterns. 

(6) 

Other  measures  of  effectiveness/efficiency. 
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h.  Analytical  models  of  tha  8SR  systems  wars  designed, 
and  manual  and  computer  requirements  specifications  and  programs 
for  descriptive  and  analytical  reports  were  developed  to  evaluate 
these  systems. 

1.  The  data  was  stratified  Into  populations  and  processed 
through  the  models  and  reports  programs. 

j.  The  computer  and  manually  generated  statistics  were 
analysed  to  determine  the  relative  system  performance.  Actual 
performance  was  compared  with  evaluation  factors  to  Isolate 
problems,  analyse  system  deficiencies,  end  develop  and  recommend 
system  improvements  as  applicable. 

B.  METHODOLOGY 

The  collection  of  data  for  SSRs  and  NIMSRs  for  the  DODSSR  Study 
was  coordinated  with  repreaentatives  of  the  SPG  and  the  Component 
study  contact  points.  The  data  collection  specification  was  for¬ 
warded  by  DODSSR  Study  letter  of  21  March  1S7S,  Subject:  Depart¬ 
ment  of  Defense  Supply  Support  Request  (DODSSR)  Study  Data  Col¬ 
lection  (Appendix  H).  Statistical  information  on  IMC,  Add  User 
and  SPR  was  collected  as  a  part  of  headquarters  and  field  research. 

1.  Data  Submitting  Activities.  Data  was  collected  from 
principal  submitters  (SICCs)  and  receivers  (IMMs)  of  SSRs  in  the 
Federal  Government.  Data  submitting  activities  included  a  com¬ 
bination  of  S1CC,  CIMM  and  W1MM  activities  as  shown  below: 


a . 

r 

(1) 

ARRCOM 

(2) 

C1RC0M 

(3) 

MIRCOM 

<*) 

TARCOM 

(5) 

TSARCOM 

b. 

Nav] 

r 

(D 

ASO 

(2) 

SPCC 

c . 

Air 

Force 

(D 

OCALC 

(2) 

OOALC 
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(3) 

SAALC 

(4) 

SMALC 

(5) 

WRALC 

d.  Marine  Corps.  MCLSBA 

e .  Defense  Logistics  Agency 


(1) 

DCSC 

(2) 

DESC 

(3) 

DGSC 

(4) 

DISC 

f.  General  Services  Administration.  Federal  Supply 

Service 

2.  Data  Collection  Requirements .  Copies  of  actual  SSR  and 
NIMSR  transactions  were  collected  from  the  submitting  activities 
in  accordance  with  the  procedures  outlined  below: 

a .  Types  of  Data 

(1)  CIMM/WIMM  Consumable  SSR  Transactions  prepared 
in  accordance  with  the  1MM  Manual. 

(a)  PDSSR .  (Program  Data  Supply  Support 
Request  Cards)  Document  Identifier  Codes  W/CWA. 

(b)  L1SSR .  (Line  Item  Supply  Support  Request 

Cards)  DIC  W/CX _ . 

(c)  LIAC .  (Line  Item  Advice/Followup  Cards) 

CX1-CX4. 

(2)  NIMSR .  (Nonconsumable  Item  Materiel  Support 
Requests)  prepared  in  accordance  with  the  Joint  Regulation  on 
Nonconsuoable  Items  (Appendix  D,  Reference  21). 

b.  Scope .  Activities  were  requested  to  submit  copies  of 
all  CIMM/WIMM/ NIMSR  transactions  generated,  submitted  or  received 
either  intra  or  inter  Service/Agency  during  the  period  1  May 
through  31  December  1978.  This  included  ell  initial  requests, 
changes,  followups,  advice  and  response  transactions.  Copies  of 
SSR  transactions  were  collected  from  both  the  SSR  submitting  and 
receiving  activities  as  a  check  and  balance  procedure,  end  to 
record  the  actual  dates  submitted  by  the  SSR  submitting  activity 
and  the  actual  date  received  by  the  SSR  receiving  activity. 
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c. 


Procedures 


(1)  CIMM/WIMM  Consumable  Transactions .  Submitting 
activities  were  asked  to  reproduce/duplicate  the  transactions  in 
punched  card  format  and  to  enter  the  date  (Julian  Date)  actually 
submitted  by  the  SSR  submitting  activity  and  the  date  actually 
received  by  the  SSR  receiving  activity  in  character  positions 
60-63  of  each  and  every  PDSSR/LISSR/LIAC  transaction. 

(2)  NIMSR .  Submitting  activities  annotated  the 
Julian  date  actually  submitted  or  received  on  each  and  every  NIMSR 
Request/Advice/Followup  form/ let  ter /memo  submitted  or  received. 

3 .  Transmission  of  Data 

a.  CIMM/WIMM  Consumables.  These  transactions  were 
requested  to  be  submitted  to  the  DODSSR  Study  Team  via  AUTODIN 
after  each  SSR  processing  cycle.  Transactions  were  received  by 
the  study  team  each  day  and  transferred  to  the  DODSSR  Data  Base 
on  a  daily  basis. 

b.  NIMSR .  These  transactions  were  in  form  of  letter 
media  and  were,  therefore,  mailed  to  the  study  group. 

4.  Data  Base.  A  data  base  was  established  on  the  computer 
at  the  Administrative  Support  Center  of  the  Defense  Logistics 
Agency  at  Cameron  Station,  Alexandria,  Virginia,  to  facilitate 
the  processing  and  analysis  of  the  SSR  data.  NIMSR  data  was  pro¬ 
cessed  manually  and  a  manual  file  was  maintained  for  NIMSR  data. 

a.  Receipt  of  Data.  The  consumable  SSRs  were  received 
at  the  AUTODIN  terminal  at  the  Communications  Center  at  Cameron 
Station.  NIMSR  transactions  were  received  by  mall  and  processed 
manually.  The  consumable  SSRs  were  routed  directly  from  the 
Communications  Center  to  the  data  processing  support  center. 

b .  Establishment  of  Data  Base 

(1)  Input  Records.  The  input  to  the  data  base  con¬ 
sisted  of  the  80  character  SSR  card  images  plus  the  AUTODIN 
header  and  trailer  cards  used  to  transmit  the  SSR  cards  over 
AUTODIN. 


Processing 


(a)  A  convention  was  established  with  the  Com¬ 
munications  Center  to  route  all  DODSSR  Data  Collection  traffic 
directly  to  the  AUTODIN  Disk  Holding  File  at  the  Support  Center. 


(b)  The  AUTODIN  Header  Content  Indicator  Code 
was  accessed  to  select  DODSSR  Data  Collection  Records  from  the 
holding  file. 


(c)  The  Communications  Routing  Identifier  of 
the  AUTODIN  Header  and  Trailer  records  were  checked  against  a 
table  of  codes  of  data  submitters* 

(d)  The  Document  Identifier  Codes  were  checked 
for  acceptability. 

(e)  An  SSR  Transaction  Master  File  Data  Record 
was  created  using  acceptable  AUTODIN  Header  and  Trailer  Records, 
and  SSR  Transaction  Records.  The  first  80  positions  of  the  out¬ 
put  record  consisted  of  the  SSR  transaction.  An  AUTODIN  date 
submitted  was  added  using  the  Julian  date  from  the  AUTODIN  Header 
Card.  An  AUTODIN  Date  Received  was  constructed  based  upon  the 
date  the  data  was  received  at  the  Data  Processing  Support  Center. 
Finally  the  Communications  Routing  Identifier  of  the  submitting 
activity  was  obtained  from  the  AUTODIN  Header  Card  to  create  a  95 
character  record. 

(f)  A  weekly  SSR  Input  Statistics  Report  was 
produced  each  week  during  the  collection  of  the  data.  This 
report  provided  counts  of  the  number  of  each  type  of  transaction 
received  by  the  data  submitting  activity.  This  report  was  used 
to  ensure  that  each  submitting  activity  was  properly  providing 
data  during  the  course  of  the  data  collection. 

(g)  A  daily  listing  of  error  transactions  was 
provided.  This  listing  was  used  to  contact  submitting  activities 
during  the  early  stages  of  the  data  collection  to  correct  initial 
errors  and  to  ensure  the  Integrity  of  the  data  being  collected. 

(3)  O.utputs 

(a)  Extracted/Reformatted  SSR  Transaction 
Master  File.  This  magnetic  tape  file  was  created  each  day  and 
consolidated  into  a  master  file  each  week.  At  the  end  of  the 
data  collection  this  file  represented  all  the  SSR  transactions 
collected  over  an  eight-month  period.  This  file  was  retained  for 
subsequent  purification  to  create  the  final  DODSSR  Data  Base. 

(b)  Dally  Transaction  Error  Listing.  This 
listing  was  used  to  monitor  the  collection  of  data. 

(c)  Weekly  SSR  Input  Statistics.  This  report 
provided  a  cumulative  count  of  all  SSR  transactions  that  had 
passed  the  initial  check  on  Data  Submitter  Codes  and  Document 
Identifier  Codes.  The  final  cumulative  report  provides  counts 

of  all  the  SSR  transactions  in  the  initial  data  base.  These  sta¬ 
tistics  are  summarised  under  data  base  statistics  in  Figure  1-1 
below. 
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(d)  Selected  Extracts.  Prior  to  our  visits  to 
operating  activities,  samples  of  transactions  were  extracted  from 
the  file  and  printed.  The  listings  of  sample  transactions  were 
used  during  field  research  to  understand  the  operation  of  the 
activities  being  visited  and  to  monitor  the  progress  of  the  data 
collection . 

c .  Purification  of  Data  Base 

(1)  Input  Records.  The  Extracted/Reformatted  SSR 
Transaction  Master  File  forms  the  initial  data  base  used  to 
create  the  final  DOOSSR  Data  Base.  This  file  contains  records 
with  valid  submitter  data  and  document  identifier  codes  and 
includes  copies  of  SSR  transactions  from  the  submitter  of  the  SSR 
transaction  and  also  from  the  receiver  of  the  SSR  transaction. 


(2)  Proce 
nate  total  duplicates, 
data  submitted  by  the 
were  then  checked  for 
for  the  same  SSR  trans 
final  DODSSR  Data  Base 
SSR  Master  File.  Coun 
showing  the  number  of 
ters  only,  those  from 
submitters  and  receive 


ssing .  The 
These  are 
same  data  su 
validity.  S 
action  were 
entitled  th 
ts  were  main 
SSR  transact 
SSR  receiver 


records  were  checked  to  ellmi- 
transactions  that  had  identical 
bmittlng  activity.  Date  fields 
ubmitter  and  receiver  records 
then  combined  to  create  the 
e  Combined  Submitter /Receiver 
tained  and  reports  produced 
ions  received  from  SSR  submit- 
s  only  and  those  from  both  SSR 


(a)  Combined  Submitter/Receiver  SSR  Master 
File .  This  magnetic  tape  file  constitutes  the  final  DODSSR  Data 
Base  used  to  develop  SSR  System  Models  and  statistical  analyses 
for  the  Quantitative  Evaluation  of  the  SSR  System.  The  file  was 
constructed  by  merging  SSR  submitter  and  receiver  records  from 
the  initial  data  base  and  includes  the  information  shown  below. 


Character 

Position 

1-59 


60-63 


64-80 


81-84 


Data  Elements 

Common  SSR  transaction  data  from 
submitter  and  receiver  records. 

Date  the  submitter  said  he  sent  the 
SSR  transaction  to  the  SSR  receiver. 

Common  SSR  transaction  data  from 
submitter  and  receiver  records. 

AUTODIN  Date  the  SSR  submitter  sent 
data  to  the  study  team. 


V* 


85-88 


AUTODIN  Date  the  transaction  was 
received  by  the  study  teaa  from 
the  SSR  submitter. 

89-95  Communications  Routing  Identifier 

of  the  SSR  submitter. 

96-99  Date  the  SSR  receiver  said  he 

received  the  SSR. 


100-103  AUTODIN  Date  the  SSR  receiver  sent 

data  to  the  study  team. 

104-107  AUTODIN  Date  the  transaction  was 

received  by  the  study  team  from 
the  SSR  Receiver. 

108-114  Communications  Routing  Identifier  of 

the  SSR  Receiver. 


(b)  Submitter /Receiver  Report.  This  report  provides 
the  number  of  records  received  from  SSR  submitters  and  receivers 
by  the  Activity  Code  To  and  Activity  Code  From  data  elements  from 
the  SSR  transaction  records*  Summarization  of  counts  are  shown 
in  the  data  base  statistics. 


d.  Data  Base  Statistics 


Figure  1-1  provides  the  volume  of  data  received  and 
entered  into  the  initial  file  and  volume  of  records  in  the  final 
DODSSR  Data  Base.  The  automated  data  base  includes  the  program 
data  records,  line  item  support  requests  and  the  line  item  advice 
cards  . 


DATA  BASE  STATISTICS 


Type  Record 

Initial 

Combined 

PDSSR 

67,881 

42,568 

LISSR 

823,488 

487,029 

LI  AC 

547,485 

371,239 

SSR  Total 

1,438,854 

900,836 

N1MSR 

4,709 

2,890 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-1 
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The  Initial  records  Include  all  the  PDSSR,  LISSR  and 
L1AC  cards  received  over  AUTODIN  and  entered  into  the  initial 
holding  file*  The  combined  count  shows  the  final  count  of  records 
in  the  DODSSR  Data  Base  after  elimination  of  duplicate  records 
and  the  merger  of  SSR  submitter  and  SSR  receiver  cards  into  a 
combined  submitter /receiver  master  record. 

The  N1MSR  initial  count  represents  the  raw  count  of 
all  the  nonconsumable  item  request  forms  that  were  received  in 
the  mail.  The  combined  count  is  similar  to  the  combined  SSR 
count  in  that  it  represents  the  final  count  of  the  records  after 
submitter  and  receiver  records  were  merged  into  a  combined  record. 
The  NIMSR  data  base  is  a  manual  data  base. 

e.  Data  Base  Stratification.  The  DODSSR  Data  Base  con¬ 
sists  of  all  the  initial,  change,  followup,  advice,  reply  and 
response  records  that  were  submitted  or  received  by  the  eighteen 
major  SSR  processors  during  an  eight-month  period.  The  data  base 
is,  therefore,  an  activity  limited,  time  limited  sample  of  the 
total  population  of  SSR  transactions.  The  sample  size  is  so 
large,  however,  that  it  approaches  the  total  population  size  in 
terms  of  statistical  validity  and  reliability.  The  data  base  was 
divided  into  a  number  of  sample  populations  to  permit  a  compara¬ 
tive  analysis  of  a  number  of  analytical  tests  and  conditions. 

(1)  Main  Population.  This  file  includes  all  com¬ 
bined  submitter/receiver  records  received  from  all  eighteen  data 
submitters  from  1  May  to  31  December  1978. 

(2)  Transition  Period.  This  sample  includes  all 
transactions  submitted  during  the  period  1  May  to  31  August  1978. 
The  new  SSR  Procedures  were  implemented  on  1  May  1978.  Any  time 
a  new  system  is  developed  and  implemented  there  is  a  transition 
period  required  to  fully  convert  from  the  old  to  the  new  system. 
During  the  early  months  after  implementation,  an  allowance  should 
be  made  for  errors  that  can  be  attributed  to  the  differences  and 
problems  associated  with  the  old  and  new  systems.  The  total 
population  was,  therefore,  divided  into  two  populations  repre¬ 
senting  the  first  and  last  four  months  of  the  data  collection  to 
permit  a  comparison  of  occurence  of  conditions  between  the  two 
periods . 


(3)  Steady  State.  This  sample  consists  of  all  trans¬ 
actions  submitted  by  all  data  submitting  activities  during  the 
period  1  September  to  31  December  1978.  The  steady  state  is  de¬ 
fined  as  that  timeframe  when  the  system  has  "settled  down,"  the 
"bugs”  in  the  system  have  been  identified  and  corrected,  users 
have  gained  familiarity  with  the  new  system  and  it  is  operating 
within  the  parameters  of  the  system,  as  designed. 
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(4)  Non-AUTODIN  Test.  The  AUTODIN  Test  was  conducted 
during  the  period  1  September  to  31  December  1978.  This  popula¬ 
tion  consists  of  transactions  that  were  submitted  or  received 
during  the  test  period  from  data  collection  activities  that  were 
no t  participating  in  the  AUTODIN  Test. 

(5)  AUTODIN  Test.  This  sample  consists  of  records 
from  activities  participating  in  the  AUTODIN  Test  during  the 
period  1  September  to  31  December  1978. 

(6)  Non-TELEFAX  Test.  Records  included  in  this  file 
consist  of  records  submitted  during  the  AUTODIN  Test  Period  from 
activities  that  participated  in  the  AUTODIN  Test  but  not  the 
TELEFAX  Test,  and  records  submitted  during  the  period  1  September 
to  30  September  1978  part  of  the  AUTODIN  Test  from  activities 
participating  in  both  the  AUTODIN  and  TELEFAX  Tests. 

(7)  TELEFAX  Test.  Records  from  the  period  1  October 
to  31  December  1978  from  activities  participating  in  both  the 
AUTODIN  and  TELEFAX  Test  are  included  in  this  sample.  The  TELEFAX 
Test  was  conducted  during  this  timeframe. 

f •  Data  Base  Processing.  Analytical  models  of  the  SSR 
systems  were  designed,  and  manual  and  computer  requirements  spec¬ 
ifications  and  programs  for  descriptive  and  analytical  reports 
to  evaluate  these  systems  were  developed.  The  stratified  popula¬ 
tions  were  processed  through  these  models  and  reports  programs. 

A  description  of  this  process  is  provided  in  Paragraph  C.  of  this 
Chapter . 

C.  ANALYSES  AND  EVALUATIONS 


The  quantitative  analyses  portrayed  in  this  section  were 
developed  in  support  of  the  problems  and  objectives  as  outlined 
in  Chapter  III,  Volume  I,  Problem  Identification.  This  quan¬ 
titative  evaluation  does  not  stand  alone,  but  must  be  considered 
in  conjunction  with  the  other  techniques  of  analyses  described  in 
this  Report.  This  evaluation  provides  descriptive  statistics  to 
describe  the  system  in  terms  of  the  population  of  supply  support 
request  methods  and  types  used  in  the  SSR  System,  and  in  terms  of 
the  activities  submitting,  receiving  and  processing  these  trans¬ 
actions.  These  transactions  were  then  analyzed  to  determine  the 
types  of  actions  that  were  taken  on  them  by  processing  activi¬ 
ties.  A  life  cycle  analysis  was  then  performed  by  stringing 
together  all  transactions  relating  to  a  request  for  the  support 
of  a  particular  item  of  supply  from  the  initial  request  until 
final  acceptance  or  rejection  of  the  supply  support  request. 

This  life  cycle  analysis  consisted  of  two  parts.  A  transaction 
analysis  was  performed  to  classify  the  chains  into  chain  pat¬ 
terns  by  analyzing  the  types,  combinations  and  order  of  types  of 
transactions  in  a  chain.  These  chain  patterns  were  then  grouped 
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into  categories,  viewed  as  networks  and  an  analysis  was  performed 
to  determine  the  time  to  accomplish  individual  events,  groups  of 
events  and  total  life  cycle  chain  time.  The  various  SSR  Systems 
described  in  Volume  II  were  evaluated  using  descriptive  and  ana¬ 
lytical  models  in  accordance  with  the  approach  described  above  to 
determine  the  relative  effectiveness  and  efficiency  of  the  various 
SSR  Systems. 


1 .  Sui 


Support  Methods 


During  the  course  of  research,  the  study  team  discovered 
that  there  were  a  number  of  methods  that  were  being  used  to  re¬ 
quest  supply  support.  Although  the  primary  area  of  concentration 
was  on  supply  support  requests  as  described  in  Chapter  IV  and 
Appendix  E  of  the  1MM  Manual,  the  study  team  requested  and  re¬ 
ceived  permission  from  the  SPG  to  obtain  Information  to  ascertain 
the  incidence  and  reason  for  the  use  of  alternative  forms  of 
supply  support  requests.  The  rationale  behind  this  was  that  if 
there  were  other  forms  in  use,  there  were  possible  problems  re¬ 
lating  to  the  understanding  of  what  should  be  used,  under  what 
conditions  one  method  should  be  used  in  place  of  another,  and 
whether  one  method  was  easier  to  use  or  another  was  deficient. 

This  section  provides  statistics  on  the  incidence  of  use  of  dif¬ 
ferent  SSR  Methods.  The  statistics  provided  on  alternative 
methods  of  supply  support  were  analyzed  in  terms  of  the  compara¬ 
tive  analysis  of  systems  and  procedures  contained  in  Chapter  V, 
Volume  I,  of  this  Report. 

Figure  1-2  displays  the  estimated  annual  volume  of  traf¬ 
fic  of  various  methods  used  to  request  supply  support.  The  volume 
is  estimated  because  different  sources  of  data  for  varying  periods 
of  time  was  used.  The  data  for  each  method  was  then  projected 
for  a  period  of  one  year.  Although  the  data  was  from  different 
periods  of  time  there  was  a  general  overlap  of  the  time  period 
for  each  of  the  methods  depicted. 

SUPPLY  SUPPORT  METHODS 
(Estimated  Annual  Volumes) 


Method 

Number 

Percent 

SSR 

422,567 

S9Z 

IMC 

16,486 

3 

Add  User 

6,949 

2 

SPR 

21,440 

5 

NIMSR 

2,890 

1 

Total 

470,332 

100X 

and  Field  Research 
Figure  1-2 
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a.  SSR «  The  data  for  SSRs  represents  the  number  of 
requests  for  individual  line  items  of  support  in  accordance  with 
the  procedures  contained  in  Chapter  IV  and  Appendix  E  of  the  IMM 
Manual.  The  data  was  obtained  from  the  DODSSR  data  collection. 
The  eight  months  of  data  in  the  data  collection  was  extended  to  a 
period  of  one  year  for  purposes  of  comparison  with  other  methods 
of  requesting  supply  support.  More  definitive  data  and  analysis 
of  SSRs  will  be  provided  under  SSR  volumes  below. 

b.  IMC 


Chapter  III  of  the  IMM  Manual  contains  procedures  for 
the  assignment  of  Item  Management  Codes  (IMCs)  to  items  subject 
to  integrated  materiel  management.  An  IMC  card,  current  Document 
Identifier  Code  LVA,  historically  has  been  used  to  convey  the 
results  of  item  management  coding  to  the  integrated  materiel  man¬ 
ager  and  to  DLSC.  These  procedures  prescribe  for  use  of  IMC  cards 
to  cover  the  following  types  of  actions: 

(1)  DLSC  Reclassification  (includes  initial  and  ret¬ 
roactive  coding  actions). 

(2)  Maintenance  coding  actions. 


(3)  Adopt  coding. 


(4)  Reactivation  actions. 


(5)  Change  actions. 


(6)  Return  coding  actions. 


The  use  of  the  IMC  for  adopt  actions  parallels  the 
use  of  SSRs  to  request  and  obtain  supply  support  for  an  item  with 
an  NSN  when  the  Military  Service  submitting  the  request  is  not  a 
recorded  user  of  the  item,  but  wants  to  become  a  user  and  request 
supply  support.  IMC  cards  can  currently  be  used  only  for  items 
with  NSNs. 


The  statistics  on  IMCs  in  Figure  1-2  represents  IMCs 
used  for  adopt  actions  and  were  extracted  for  the  period  May  1978 
to  March  1979  and  extended  to  a  period  of  one  year. 

c.  Add  User.  Prior  to  1  May  1978  an  activity  of  a 
Military  Service  could  be  recorded  as  a  user  of  an  item  managed 
by  an  IMM  by  submitting  an  IMC,  SSR  or  an  Add  User  Transaction 
DIC  LAU.  With  the  implementation  of  the  revised  procedures  in 
the  IMM  Manual  effective  1  May  1978,  the  Services  can  no  longer 
use  the  Add  User  Transaction  to  be  recorded  as  a  user  on  an  IMM 
item.  However,  the  IMM  Manual  in  Chapter  III  provides  for  the 
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IMMs  to  record  the  incidence  of  demand  from  requisitions  by 
Services  not  officially  recorded  as  users  of  an  NSN  item.  Pro¬ 
cedures  are  then  provided  to  automatically  record  the  Service  as 
a  user  on  the  item  or  to  contact  the  Service  and  request  an  SSR 
and  then  record  the  Service  as  a  user.  The  add  user  statistics 
shown  in  Figure  1-2  represent  the  volume  of  transactions  of  this 
nature  and  were  taken  from  the  same  source  as  the  IMC  statistics. 
This  statistic  represents  a  method  to  provide  the  benefits  of 
supply  support  when  an  SSR  or  IMC  has  not  been  used  by  a  Service 
that  has  been  requisitioning  an  item. 

d.  SPR.  Chapter  XI  of  MILSTRAP,  DoD  4140. 22-M,  (Appen¬ 
dix  D,  Reference  26),  provides  procedures  for  submitting  Special 
Program  Requirement  Transactions  (SPRs)  to  forecast  requirements 
for  items  required  to  support  special  programs  or  projects  which 
are  of  a  nonrepetitive  nature  and  cannot  be  forecasted  by  the  ICP 
based  on  demand  data,  and  which  have  the  greatest  probability  of 
materializing  and  resulting  in  the  eventual  submission  of  requisi¬ 
tions.  SSRs  on  the  other  hand,  are  intended  to  submit  require¬ 
ments  for  items  with  estimated  repetitive  demand.  The  data 
depicted  for  SPRs  was  extracted  during  research  at  DLA  Headquar¬ 
ters  from  reports  produced  by  DLA.  The  volume  data  for  SPRs 
depicted  in  Figure  1-2  represents  forecasts  of  demand  require¬ 
ments  for  the  Air  Force  for  specific  aircraft  for  Fiscal  Year 
1978.  Based  upon  discussions  with  DLA  Headquarters  personnel 

and  reviews  of  DLA  trip  reports  covering  support  problems  for  Air 
Force  aircraft,  it  is  the  opinion  of  the  study  group  that  the 
data  shown  in  the  figure  represents  the  use  of  SPRs  to  obtain 
supply  support  in  lieu  of  the  use  of  SSRs. 

e.  NIMSR .  A  Nonconsumable  Item  Materiel  Supply  Support 
Request  (NIMSR)  is  prepared,  submitted  and  processed  in  accor¬ 
dance  with  the  joint  regulation  for  support  of  multiused  noncon¬ 
sumable  items  (Appendix  D,  Reference  21).  Although  the  DODSSR 
Study  was  limited  to  consumable  items,  permission  was  granted  by 
the  SPG  to  collect  data  on  the  volume  and  usage  of  NIMSRs  for 
comparative  purposes.  The  data  for  NIMSRs  was  obtained  from  the 
DODSSR  Data  Collection  and  is  shown  here  to  compare  the  relative 
volume  with  the  traffic  of  other  SSR  methods. 

f.  Summary .  Conventional  supply  support  requests  (SSRs) 
are  used  in  89%  of  the  cases  to  request  and  obtain  supply  support 
for  consumable  and  nonconsumable  items  of  support.  If  noncon¬ 
sumables  are  excluded,  SSRs  are  used  in  90%  of  the  cases.  This 
means  that  10%  of  the  time  an  alternative  method  is  being  used  in 
place  of  an  SSR.  Requisitions,  per  se,  are  not  shown  here  because 
a  requisition  does  not  request  the  performance  of  item  management 
coding  or  cataloging  actions  and  does  not  provide  a  forecast  of 
materiel  requirements.  A  requisition  is  a  request  for  a  specific 
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amount  of  materiel  which  is  to  be  issued,  to  be  delivered  to  a 
particular  activity.  Chapter  V,  Volume  I,  of  this  Report  com¬ 
pares  and  contrasts  the  procedures  that  specify  the  use  of  SSRs 
and  alternative  methods  for  requesting  supply  support. 

2.  Supply  Support  Request  (SSR)  Packages.  The  use  of  the 
terminology  "Supply  Support  Methods"  above  was  used  to  distin¬ 
guish  between  supply  support  requests  and  other  alternative 
vehicles  used  to  accomplish  supply  support  actions.  The  sta¬ 
tistical  information  shown  for  SSRs  refers  to  SSRs  as  described 
in  the  functional  requirements  section  of  Volume  I  of  this  Report 
and  Chapter  IV  and  Appendix  E  of  the  IMM  Manual.  The  DODSSR  Data 
Base  was  used  to  generate  the  information  shown  on  SSRs  in  this 
section . 


a .  Package  Volumes 

Supply  support  requests  are  forwarded  from  SSR  sub¬ 
mitters  (SICCs)  to  SSR  receivers  (IMMs)  in  SSR  packages.  Figure 
1-3  displays  volumes  of  SSR  packages  submitted  during  the  period 
of  the  DODSSR  Data  Collection.  There  are  two  kinds  of  packages 
represented  by  this  figure,  PDSSR  and  LISSR  packages. 

SSR  PACKAGES 
(Number  of  Cards) 


Type 

f~  CIMM  1 

WIMM 

PDSSR 

KHBH 

2,633 

LISSR 

Request 

Catalog 

404,316 

76,507 

7,483 

Total 

520,758 

10,116 

Source:  DODSSR  Data  Collection;  Main  Population 

Figure  1-3 

(1)  PDSSR  packages  consist  of  a  PDSSR  header  card 
and  associated  LISSR  cards  with  the  same  control  information 
being  forwarded  from  a  specific  submitter  to  a  specific  receiver. 
A  PDSSR  package  may  contain  as  few  as  two  cards,  one  PDSSR  header 
and  one  LISSR  or  may  contain  as  many  as  several  thousand  cards. 
The  average  PDSSR  package  for  a  CIMM  item  contains  13  cards  in¬ 
cluding  the  header  card.  WIMM  PDSSR  packages  contain  an  average 
of  four  cards  including  the  header  card.  The  difference  in  the 
average  number  of  cards  for  CIMM  and  WIMM  items  is  attributable 
to  the  fact  that  LISSR  catalog  cards  apply  only  to  CIMM  items. 
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Also  as  will  be  shown  under  LXSSR  statistics  belov,  SSRs  for  WIMM 
items  are  generally  for  NSN  items.  An  NSN  request  requires  a 
minimum  of  one  LISSR  card  while  a  part  number  request  requires 
additional  cards  to  supply  catalog  data. 

The  average  number  of  requests  in  a  PDSSR  pack¬ 
age  is  seven  for  a  C1MM  and  three  for  WIMM.  A  request  consists 
of  a  request  transaction  with  its  associated  catalog  cards  for 
the  same  item  of  support. 

(2)  LISSR  packages  are  comprised  of  all  the  request 
and  catalog  cards  for  the  same  item  of  support  on  the  same  date 
of  request.  A  LISSR  package  can  contain  from  one  to  more  than 
100  cards.  The  maximum  experienced  in  the  data  collection  was 
165.  LISSR  packages  for  a  CIMM  item  contained  an  average  of  two 
cards  while  WIMM  LISSR  packages  contained  an  average  of  1.05 
cards.  Restriction  of  use  of  catalog  cards  to  CIMM  items  and 
restriction  of  part  number  requests  for  WIMM  items  to  joint  ser¬ 
vice  provisioning  actions  accounts  for  the  difference  in  the  CIMM 
and  WIMM  averages. 

b.  Submltter/Recelver  Relationships.  Submission  of  pro¬ 
gram  data  and  line  item  SSR  packages  from  SICCs  to  IMMs  is  dis¬ 
played  by  submitter  (SICC)  and  receiver  (IMM)  to  show  the  relative 
volume  of  traffic  and  the  relationship  among  the  major  contribu¬ 
tors.  The  data  is  displayed  separately  for  CIMM  and  WIMM  items. 

( 1 )  Program  Data  Supply  Support  Requests  (PDSSRs) 

(a)  CIMM .  Figure  1-4  presents  a  picture  of  the 
number  of  program  data  packages  submitted  during  the  data  collec¬ 
tion  period.  The  Defense  Logistics  Agency  received  94.3%  of  all 
the  PDSSR  Packages.  The  General  Services  Administration  received 
3.7%  of  the  traffic,  while  TARCOM  received  0.6%.  The  Air  Force 
was  the  largest  Service  submitter  at  42.3%,  while  SPCC  and  SMALC 
were  the  largest  activity  submitters  with  about  20%  each.  The 
largest  single  receiver  of  PDSSRs  was  DESC  with  35.6%.  The 
"Other”  column  represents  invalid  use  of  document  identifier 
codes  or  transmission  to  other  than  a  CIMM. 

(b)  WIMM  .  The  PDSSR  submi 1 1 e r / r e ce i ver  rela¬ 
tionships  for  WIMM  traffic  is  shown  in  Figure  1-5.  The  traffic 
is  much  smaller  than  for  CIMM  items.  The  Air  Force  and  Navy  are 
the  largest  submitters  and  receivers  of  WIMM  traffic.  The  Navy 
sent  25.6%  and  received  34.9%  of  the  tc/tal  traffic.  The  Air 
Force  sent  40.8%  and  received  31.6%  of  the  total  traffic.  Most 
of  the  Navy  and  Air  Force  business  was  with  each  other.  ASO  was 
the  single  biggest  submitter  and  receiver  with  25.5%  of  the  out¬ 
going  and  18.8%  of  the  incoming  traffic. 
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PDSSR  SUBMITTER/ RECEIVER  RELATIONSHIPS 
(Number  of  CIMM  Transactions  by  Activity) 


Submitter 

Receiver  | 

DCSC 

DESC 

DGSC 

DISC 

GSA 

TARCOM 

Other 

Total 

ARRCOM 

54 

144 

66 

243 

46 

1 

23 

577 

CERCOM 

37 

671 

278 

177 

31 

0 

13 

1,207 

MIRCOM 

18 

264 

102 

173 

29 

o 

5 

591 

TARCOM 

402 

113 

181 

469 

16 

0 

12 

1,193 

TSARCOM 

222 

326 

242 

720 

90 

7 

64 

1,671 

ASO 

390 

1,760 

772 

1,116 

65 

13 

6 

4,122 

SPCC 

1,609 

2,750 

1,352 

1,797 

243 

20 

230 

8,001 

OCALC 

14 

11 

25 

33 

3 

0 

0 

86 

OOaLC 

15 

15 

240 

36 

11 

0 

4 

321 

SAALC 

1,018 

457 

877 

2,624 

57 

35 

56 

5,124 

SMALC 

27 

5,621 

2,049 

511 

15 

2 

70 

8,295 

WRALC 

493 

516 

549 

798 

621 

61 

46 

3,084 

MCLSBL 

297 

393 

200 

379 

38 

77 

36 

1,420 

EGICP 

0 

102 

67 

119 

0 

0 

0 

288 

SiCP 

69 

4 

44 

17 

0 

0 

0 

134 

A1CP 

1 

1 

1 

0 

0 

1 

0 

4 

OTHER 

688 

1,054 

937 

904 

218 

9 

7 

3,817 

TOTAL 

■fl 

14,202 

ns 

1,483 

226 

572 

Hill 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-4 
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Figure  1-5 


(  2  )  Line  Item  Su 


(a)  CIMM.  The  data  In  Figure  1-6  for  LISSRs  is 
comparable  to  the  PDSSR  traffic  for  CIMM  items.  Although  DLA 
received  roughly  the  same  percentage  of  overall  traffic,  it  is 
interesting  to  note  that  the  DESC  volume  for  LISSRs  was  57. 3%, 
over  half  the  total  traffic,  while  the  DESC  volume  for  PDSSRs 
from  Figure  1-4  was  35. 6%.  This  indicates  that  DESC  is  receiving 
provisioning  submissions  with  a  greater  number  of  items  per  pack¬ 
age.  Although  the  Air  Force  submits  more  PDSSR  Packages,  the 
Navy  with  43. 3%  of  the  LISSR  traffic  submitted  is  the  largest 
submitting  Service.  SPCC  is  the  largest  activity  submitter  with 
30. 4%,  while  SMALC  is  second  with  20.2%.  The  largest  activity  to 
activity  relationships  are  with  DESC  and  SPCC  (21.8%),  and  DESC 
and  SMALC  (17.1%). 


(b)  WIMM 

LISSR  Packages  submitted  for  WIMM  items  are 
similar  to  those  for  PDSSR  Packages  for  WIMM  items  as  shown  in 
Figure  1-7.  The  Navy  and  Air  Force  are  the  largest  Service  sub¬ 
mitters  with  27.2%  and  37.1%,  respectively.  The  Navy's  SPCC  is 
the  largest  activity  submitter  with  27%.  The  Navy  is  the  largest 
receiver  of  LISSRs  with  36.2%  of  the  action  split  about  evenly 
between  ASO  and  SPCC.  The  volume  of  LISSRs  for  WIMM  items  appears 
to  be  lower  than  it  should  be  due  to  the  use  of  C series  Docu¬ 
ment  Identifier  Codes  for  WIMM  items.  The  C _  series  is  reserved 

for  CIMM  items. 


The  Air  Force  data  does  not  show  any  intra¬ 
service  traffic  which  is  consistent  with  Air  Force  system  design 
and  Implementation.  The  ASO  in  the  Navy  sends  about  9.6%  of  its 
outgoing  traffic  to  SPCC  on  an  intraservice  basis.  However,  SPCC 
does  not  show  any  WIMM  LISSRs  sent  to  ASO.  The  intraservice 
traffic  in  Army  is  rather  low.  The  Army,  like  the  Navy,  specifies 
the  use  of  SSRs  for  intraservice  use.  The  low  incidence  of  use 
of  WIMM  SSRs  for  the  Army,  and  SPCC  in  the  Navy  may  be  attribut¬ 
able  to  the  use  of  C _  series  documents  that  make  up  a  large  part 

of  the  "Other"  column  in  Figure  1-6. 


>es  of  Submissions 


(1)  PDSSR 


(a)  CIMM 


Figure  1-8  breaks  down  PDSSR  submissions  by 
the  type  of  submission.  A  Type  of  Change  Code  (TCC)  is  used  to 
indicate  the  type  of  submission  of  an  SSR.  An  original  submission 
reflects  a  complete  or  incremental  submission  of  provisioning  or 
other  program  data  and  SSRs.  A  change  indicates  a  design  or  pro¬ 
gram  change  to  an  original  submission.  Nonprovisioning  is  not 
defined  in  the  IMM  Manual.  The  "Other"  column  represents  Invalid 
characters  including  blank  submissions  of  a  TCC. 
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LISSR  SUBMITTER/ RECEIVER  RELATIONSHIPS 
(Number  of  Cl MM  Transactions  by  Activity) 


|  Receiver  | 

DCSC 

DESC 

DGSC 

DISC 

GSA 

TARCOM 

OTHER 

TOTAL 

70 

257 

99 

415 

80 

1 

27 

949 

70 

3,369 

1,141 

666 

77 

0 

36 

5,359 

21 

784 

130 

350 

29 

o 

9 

1,323 

1,324 

180 

348 

1,502 

26 

1 

14 

3,395 

1,831 

1,434 

846 

4,863 

194 

19 

156 

9,343 

2,010 

21,724 

3,459 

7,977 

176 

56 

11 

35,413 

4,787 

59,973 

5,638 

11,029 

895 

33 

1,213 

83,568 

63 

37 

87 

145 

3 

0 

0 

335 

38 

206 

555 

1,117 

226 

0 

93 

2,235 

3,732 

1,378 

2,194 

15,647 

122 

258 

108 

23,439 

77 

46,922 

6,096 

2,245 

23 

9 

74 

55,446 

3,619 

3,597 

3,179 

4,237 

6,141 

268 

47 

21,088 

3,433 

2,825 

771 

5,014 

156 

274 

58 

12,533 

0 

105 

92 

206 

0 

0 

0 

403 

116 

3 

20 

17 

0 

0 

0 

156 

2 

1 

1 

0 

0 

1 

0 

5 

1,278 

14,490 

1,502 

2,054 

272 

24 

39 

19,659 

■HHnHHHHHHn 

944 

mm 

Total 


Source:  DOOSSR  Data  Collection;  Main  Population 


Figure  1-6 
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PDSSR  VOLUMES  FROM  SICC  TO  CIMM 
(Rov  Percent  by  Submitter) 


e  of  Submission 


Submitter 


ARRCOM 

CERCOM 

M1RCOM 

TARCOM 

TSARCOM 


ASO 

SPCC 


84.82 


100. OX 
94.1 


96. IX 


rovisionin 


Other 


3.1% 

6.3 

1.5 
4.9 

5.5 


OCALC 

OOALC 

SAALC 

SMALC 

WRALC 


Air  Force 


MCLSBL 


61. 62 

32.7 
90.9 

95.7 
66.0 


0.0% 

0.0 

0.4 

3.4 

2.6 


38.42 

67.3 
8.7 
0.8 

31.4 


0.0% 

0.0 
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Only  IX  of  the  program  data  cards  received 
In  the  data  collection  represented  submission  of  changes.  The 
lov  usage  among  submitters  was  fairly  uniform.  The  use  of  the 
designation  "Nonprovisioning"  fluctuated  widely  among  submitters. 
Note  that  ARRCOM  in  the  Army  has  roughly  a  50/50  split  of  provi¬ 
sioning  and  nonprovisioning.  ASO  in  the  Navy  did  not  submit  any 
nonprovisioning  PDSSRs.  Submissions  of  provisioning  and  nonpro¬ 
visioning  also  vary  widely  among  Air  Force  activities. 

The  review  of  the  systems  design  and  imple¬ 
mentation  at  the  data  submitting  activities  indicates  a  wide  dis¬ 
parity  in  the  use  of  these  codes.  The  use  of  these  codes  is  not 
consistent  for  initial,  follow-on,  reprovisioning,  and  equipment 
design  changes.  Some  of  the  systems  do  not  provide  for  the  auto¬ 
mated  generation  of  SSRs  for  equipment  design  changes.  Nonpro- 
sioning  is  sometimes  used  for  follow-on  or  reprovisioning  and 
sometimes  for  equipment  design  changes.  Sometimes  design  changes 
are  not  forwarded  by  SSRs.  Submission  of  requirements  for  equip¬ 
ments  delivered  after  the  first  year  is  also  mixed.  Current  DoD 
policy  and  criteria  for  when  an  original  SSR  or  SSR  change  should 
be  submitted  is  either  not  clear  or  conflicts  from  directive  to 
directive.  The  procedures  section  of  Chapter  IX  will  provide  a 
comparison  of  this  policy. 

(b)  W 1MM .  The  types  of  FDSSR  submissions  shown 
in  Figure  1-9  represent  the  same  types  of  patterns  as  for  CIMM 
submissions;  an  extremely  low  0.2X  change  submissions  with  a  wide 
fluctuation  of  the  use  of  nonprovisioning  among  activities.  The 
general  patterns  remained  the  same  except  for  Air  Force  where  the 
ratio  of  nonprovisioning  to  provisioning  was  higher  for  WIMM 
while  it  was  lower  for  CIMM.  Overall  nonprovisioning  actions 
were  up  13.4%  over  CIMM  actions.  The  same  explanation  as  was 
provided  for  CIMM  above  applies  for  WIMM. 

(2)  LISSR 

(a)  CIMM .  The  statistics  in  Figure  1-10  for 
LISSKs  for  CIMM  items  show  the  same  variability  in  application  of 
Type  of  Change  Codes  as  for  POSSRs .  However,  it  should  be  noted 
that  the  total  percentage  of  nonprovisioning  LlSSRs  submitted  is 
7.8X  as  compared  with  13. OX  for  PDSSRs.  This  indicates  that  the 
number  of  cards  in  a  nonprovisioning  PDSSR  package  tends  to  be 
less  than  for  provisioning.  The  same  situation  prevails  for 
change  submissions  with  the  percentage  dropping  from  1.0X  for 
PDSSR  packages  to  0.4X  for  LISSR  packages.  The  less  than  one- 
half  of  one  percent  figure  for  LISSR  changes  tends  to  confirm  the 
observations  made  above  for  PDSSR  changes  that  there  needs  to  be 
a  clarification  of  the  definitions  and  usage  for  the  use  of  the 
designation  ''Nonprovisioning''  and  "Change"  in  the  submission  and 
processing  of  supply  support  requests. 

(b)  WIMM.  The  LISSR  data  for  WIMM  items  in 
Figure  i-ll  are  comparable  to  those  for  PDSSRs.  This  is  attri¬ 
buted  to  the  high  usage  of  NSN  SSRs  for  WIMM  items. 
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PDSSR  VOLUMES  FROM  SICC  TO  WIMM 
(Row  Percent  by  Submitter) 


Type  of  Submission 


Submitter 

Original 

Change 

Non¬ 

provisioning 

Other 

ARRCOM 

43.7% 

0.0 

52.1% 

4.2% 

CERCOM 

77.0 

0.0 

17.9 

5.1 

MIRCOM 

98.4 

0.0 

0.0 

1.6 

TARCOM 

98.0 

0.0 

0.0 

2.0 

TSARCOM 

89.6 

0.7 

1.5 

8.2 

Army 

81.1% 

0.3% 

13.5% 

mrnm 

ASO 

100.0% 

0.0% 

0.0% 

I 

SPCC 

0.0 

0.0 

100.0 

Navy 

99.6% 

0.0% 

0.4% 

0.0% 

OCALC 

59.5% 

2.4% 

38.1% 

mgm 

OOALC 

48.6 

0.0 

51.4 

■IjB 

SAALC 

34.7 

0.4 

64.9 

SMALC 

64.7 

0.3 

34.7 

-mtmt 

WRALC 

27.6 

0.0 

72.4 

wiil- 

Air  Force 

44.8% 

0.3% 

54.8% 

0.1% 

MCLSBL 

82.6% 

0.0% 

15.6% 

1.8% 

HC 

82.6% 

0.0% 

15.6% 

1.8% 

EGICP 

100.0% 

0.0% 

0.0% 

0.0% 

SICP 

73.3 

0.0 

0.0 

26.7 

AICP 

94.8 

0.0 

5.2 

0.0 

CG 

93.0% 

0.0% 

4.7% 

2.3% 

Other 

88.1% 

0.0% 

7.9% 

4.0% 

Total 


2 


0.2% 


26.4% 


1.3% 


LISSR  VOLUMES  FROM  SICC  TO  CIMM 
(Row  Percent  by  Submitter) 


Type  of  Submission 


Submitter 

Original 

Change 

Non- 

provisioning 

Other 

ARRCOM 

60.0% 

0.1% 

39.5% 

0.4% 

CERCOK 

89.3 

0.2 

10.5 

0.0 

MIRCOM 

98.6 

0.9 

0.0 

0.5 

TARCOM 

98.0 

0.7 

0.5 

0.7 

TSARCOM 

93.1 

1.6 

5.1 

0.2 

Army 

91.8% 

0.9% 

7.0% 

0.3% 

ASO 

1  100.0% 

0.0% 

0.0% 

0.0% 

SPCC 

1  98.2 

0.0 

1.8 

0.0 

Navy 

98.7% 

0.0% 

1.3% 

0.0% 

OCALC 

66.3% 

0.0% 

33.7% 

0.0% 

OOALC 

88.3 

1  0.0 

11.7 

0.0 

SAALC 

89.7 

0.2 

10.1 

0.0 

SMALC 

98.1 

1.4 

0.5 

0.0 

WRALC 

41.8 

0.5 

57.7 

0.0 

Air  Force 

84.3% 

0.4% 

i 

15.3% 

0.0% 

MCLSBL 

96.7% 

0.0% 

3.0% 

0.3% 

MC 

96.7% 

0.0% 

3.0% 

0.3% 

EGICP 

35.7% 

0.0% 

12.9% 

51.4% 

SICP 

32.1 

0.0 

3.8 

64.1 

AICP 

100.0 

0.0 

0.0 

0.0 

CG 

35.3% 

0.0% 

10.3% 

54.4% 

Other 

85.3% 

0.0% 

14.1% 

0.6% 

Total 

91.6% 

0.4% 

7.8% 

0.2% 

Source:  DODSSR  Data  Collection;  Main  Population 

Figure  1-10 


LISSR  VOLUMES  FROM  SICC  TO  WIMM 
(Row  Percent  by  Submitter) 


Submitter 

Type  of 

Submisaion 

IBM 

Other 

ARRCOM 

45. 9% 

0.0% 

54.1% 

0.0% 

CERCOM 

88.5 

0.0 

9.5 

2.0 

M1RCOM 

100.0 

0.0 

0.0 

0.0 

TAR COM 

98.4 

0.0 

0.0 

1.6 

TSARCOM 

97.9 

0.9 

0.8 

0.4 

Army 

88.6% 

0.2% 

10.3% 

0.9% 

ASO 

100.0% 

0.0% 

0.0% 

— 

SPCC 

64.3 

0.0 

35.7 

Navy 

99.7% 

0.0% 

0.3% 

0.0% 

OCALC 

70.7% 

2.0% 

25.3% 

2.0% 

OOALC 

53.3 

0.0 

46.7 

0.0 

SAALC 

36.8 

0.2 

63.0 

illiM 

SMALC 

50.6 

0.1 

49.2 

hhhcjVH^H 

WRALC 

17.3 

0.0 

82.7 

Air  Force 

37.4% 

0.2% 

62.3% 

0.1% 

MCLSBL 

76.3% 

0.0% 

22.1% 

1.6% 

MC 

76.3% 

0.0% 

H 

• 

CM 

CM 

1.6% 

EG1CP 

100.0% 

0.0% 

0.0% 

0.0% 

SICP 

0.0 

0.0 

0.0 

100.0 

AICP 

97.9 

0.0 

2.1 

0.0 

CG 

V0 

O 

• 

o 

N 

0.0% 

1.9% 

8.1% 

Other 

97.5% 

0.0% 

1.6% 

0.9% 

Total 

71.3% 

0.1% 

28.0% 

0.6% 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  I-il 
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a .  Population  Volumes 

The  volume  of  records  for  each  of  the  populations 
used  in  generating  reports  for  this  quantitative  analysis  is 
shown  in  Figure  1-12. 

POPULATION  VOLUMES 


Population 

Number 

Populat ion 

Name 

Number 

Records 

0 

Main 

900,836 

1 

Transition 

484,051 

2 

Steady  State 

315,015 

3 

Non-AUTODIN  Test 

299,513 

4 

AUTODIN  Test 

15,502 

5 

Non-TELEFAX  Test 

5,623 

6 

TELEFAX  Test 

9,879 

Source:  DODSSK  Data  Collection 

Figure  1-12 

The  Main  Population  which  consists  of  all  the  consum¬ 
able  SSR  Transactions  collected  during  the  entire  data  collection 
period  was  subdivided  into  the  Transition  and  Steady  State  per¬ 
iods.  Populations  0,  1,  and  2  were  then  compared  to  determine 
if  there  were  any  bias,  problems  or  errors  that  could  be  attribut¬ 
able  to  the  old  system  or  to  the  transition  to  a  new  system. 

The  first  thing  that  was  noticed  was  that  there  were 
a  number  of  transactions  with  a  start  date  (Date  of  Request)  prior 
to  the  1  May  1978  implementation  date  of  the  new  SSR  Procedures. 
These  were  transactions  that  had  been  either  created  and  held 
until  the  start  date  or  were  follow-on  transactions  to  an  SSR  that 
had  been  created  under  the  old  system.  These  transactions  were 
eliminated  in  the  extraction  of  Populations  1  and  2;  therefore. 
Populations  1  and  2,  which  are  the  first  and  second  halves  of  the 
data  collection  period  respectively,  do  not  add  up  to  the  count 
of  records  for  the  main  population. 

The  main  population  was  then  subdivided  into  provi¬ 
sioning  and  nonprovisioning  transactions  and  a  report  was 
generated  to  show  the  counts  of  the  different  types  of  transac¬ 
tions  in  these  two  populations  to  determine  if  there  was  any 
significant  difference  for  provisioning  and  nonprovisioning 
actions.  Nonprovisioning  transactions  account  for  about  82  of 
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the  total  population.  On  W1MM  items,  99%  of  the  provisioning 
requests  are  for  stock  numbered  items  as  compared  to  92Z  for  noa- 
provisloning  WIMM  items.  More  CXF  Item  Name  Cards  are  sent  for 
nonpro vis ioning  than  provisioning  items.  Seventy-one  percent  of 
nonpro vis ionlng  and  35%  of  the  provisioning  items  were  accom¬ 
panied  by  an  Item  Name  Card.  This  is  probably  due  to  the  non¬ 
availability  of  technical  data  for  nonprovisioning  items. 

An  analysis  was  then  performed  on  Populations  0,  1, 
and  2.  The  proportion  of  transactions  within  these  populations 
were  similar  for  the  submitting  and  receiving  activities.  How¬ 
ever,  a  comparison  of  the  populations  with  each  other  Indicated 
certain  differences  as  shown  in  Figure  1-13. 

POPULATION  COMPARISON 
(Percent  of  Column  Total) 


Transaction  Type 

Population 

0 

1 

2 

Request 

39% 

35% 

47% 

Catalog 

10 

12 

9 

Advice 

36 

36 

35 

Offer 

1 

1 

1 

Followup 

8 

9 

5 

Response 

6 

7 

3 

Total 

100% 

100% 

100% 

Source:  DODSSR  Data  Collection 


Figure  1-13 

The  ratio  of  requests  to  the  total  population  of 
transactions  is  much  higher  in  Population  2  than  for  the  other 
populations.  This  is  attributable  to  the  higher  number  of  fol¬ 
lowup  and  response  transactions  that  were  generated  during  the 
initial  start  of  the  new  system.  Some  of  the  submitting  activi¬ 
ties  generated  followups  for  each  SSR  in  their  suspense  files 
that  had  not  been  closed  out;  therefore  Population  0  has  a  dis¬ 
proportionate  number  of  followup  and  response  transactions.  In 
addition,  one  of  the  Services  had  an  error  in  their  system  that 
caused  the  generation  of  Add  Reference  Number  Catalog  Cards  which 
should  not  have  been  generated,  since  the  reference  numbers  were 
already  recorded  in  the  Federal  Catalog  Files. 

An  analysis  was  also  performed  of  the  distribution  of 
Action  Taken  Codes  (ATCs)  for  each  of  the  populations  shown.  This 
revealed  that  there  were  a  number  of  invalid  codes  that  were  used 
during  the  Initial  period,  that  were  not  present  in  the  last  half 
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of  the  data  collection.  Some  of  these  errors  were  codes  that 
never  existed  and  some  were  codes  that  were  present  under  the  old 
procedures  but  were  not  valid  codes  for  the  new  procedures. 


The  rest  of  the  data  in  the  populations  seems  to  be 
more  comparable  among  the  populations.  However,  since  displaying 
data  for  Populations  0,  1,  and  2  would  be  redundant,  and  since 
the  data  in  Population  2  (Steady  State)  appears  to  be  more  re¬ 
flective  of  the  actual  ongoing  system  for  most  purposes  and  more 
compatible  with  the  data  in  the  test  populations.  Population  2 
was  chosen  as  the  base  population  for  in-depth  analysis  and  for 
comparison  with  the  test  populations. 

b .  Request  Transactions 

( 1 )  Estimated  Annual  Volumes  and  Proportions 

There  are  three  basic  types  of  request  transac¬ 
tions  that  can  be  forwarded  from  a  SICC  (submitter)  to  an  I MM 
(receiver);  stock  numbered  items,  part  numbered  items  and  per¬ 
manent  system  control  numbered  items.  Figure  1-14  provides  an 
estimate  of  the  annual  volume  of  SSRs  for  CIMM  and  W1MM  items. 
These  volumes  have  been  projected  from  the  eight  months  of  data 
collected  during  the  course  of  the  study. 

ESTIMATED  ANNUAL  GROSS  SSR  VOLUMES 
(Number  of  Tranactions) 


Low 

High 

Average 

CIMM 

WIMM 

375,000 

7,500 

450,000 

15,000 

425,000 

9,750 

Total 

382,500 

465,000 

434,750 

Source:  DODSSR  Data  Collection 


Figure  1-14 

These  volumes  were  projected  from  the  data 
received  during  the  eight-month  data  collection  period.  The  low, 
high  and  average  were  computed  as  shown  to  make  allowances  for 
fluctuations  in  the  amount  of  provisioning  actions  during  any 
given  year,  transactions  not  received  during  the  data  collection 
and  erroneous  transactions  that  were  purged  from  the  data  base. 
The  information  shown  includes  initial  requests,  changes  and  re¬ 
submissions  of  requests  that  may  have  been  previously  rejected. 
Resubmissions  are  treated  as  new  transactions  by  the  receiving 
activity.  Other  analyses  in  this  Chapter  will  consider  the 
netting  out  of  change  and  resubmission  of  transactions  over  the 
life  cycle  of  a  request. 


The  proportion  of  requests  for  CIMM  and  WIMM 
items  is  shown  in  Figure  1-15. 

S SR  IMM  PROPORTIONS 
(Percent  CIMM/WIMM) 


Low 

High 

■EEEESH 

CIMM 

96% 

98% 

97% 

WIMM 

2% 

4% 

3% 

Source:  DOOSSR  Data  Collection 


Figure  1-15 

The  proportion  of  CIMM  items  is  very  high  as 
compared  with  the  WIMM  traffic.  It  should  be  noted  that  under 
the  WIMM  retention  procedures  new  items  are  generally  retained  by 
the  provisioning  activity.  Part  numbered  SSRs  are  restricted  to 
Joint  provisioning  actions  by  the  SSR  Procedures.  This  results 
in  a  high  retention  rate  for  part  numbered  items  and  the  hi^ h 
proportion  of  stock  numbered  SSRs  for  WIMM  items  as  shown  in 
Figure  1-16. 

SSR  TRANSACTION  PROPORTIONS 

(Percent  DIC  for  WIMM  Items) 


■xrai 

Low 

High 

Average 

a 

90.0% 

0.9% 

0.0% 

99.0% 

9.5% 

0.0% 

94.0% 

6.0% 

0.0% 

Source:  DODSSR  Data  Collection 


Figure  1-16 

The  wide  fluctuation  of  10%  in  stock  numbered 
items  versus  part  numbered  items  is  attributable  to  the  Influence 
of  the  timing  of  joint  provisioning  actions  on  the  rather  small 
number  of  WIMM  SSRs. 

By  contrast,  as  shown  in  Figure  1-17,  the  ratio 
of  NSN  to  part  numbered  items  was  quite  steady  for  all  CIMM  popu¬ 
lations  in  the  data  collection  with  only  slightly  more  NSN  than 
part  numbered  SSRs.  The  actual  spread  may  be  slightly  higher  if 
changes  and  resubmissions  were  netted  out,  since  there  is  a  ten¬ 
dency  to  have  more  changes  and  resubmissions  for  part  numbered 
items.  Permanent  system  control  items  constitute  a  very  small 
part  of  CIMM  items  and  were  nonexistent  for  WIMM  items. 
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S SR  TRANSACTION  PROPORTIONS 
(Percent  DIC  for  CIMM  Items) 


Type 

Low 

■mi 

IKESZEGM 

NSN 

PN 

PSCN 

51.0% 
47 .0% 
0.1% 

53.0% 

49.0% 

0.2% 

52.0% 

48.0% 

0.15% 

Source:  DODSSR  Data  Collection 


Figure  1-17 

(2)  Actual  Volumes.  The  actual  volumes  of  request 
transactions  displayed  in  the  next  series  of  tables  show  the 
principal  submitters  and  receivers  of  SSRs  for  both  CIMM  and 
HIMM  items*  Relationships  are  further  shown  by  Component  and 
activity  separately  for  stock  numbered,  part  numbered  and  perma¬ 
nent  system  control  numbered  items. 

(a)  CIMM 

Figures  1-18  and  1-19  show  the  proportion 
of  supply  support  requests  by  SSR  submitters.  The  number  of  SSRs 
for  the  type  CXA-NSN,  CXB-part  number  or  CXC-PSCN  may  vary  by 
activity  during  any  given  year  or  month  of  the  year.  However, 
the  system  and  Service  totals  were  fairly  stable  over  the  entire 
data  collection  period. 


The  Air  Force  an 
submitters  of  SSRs  during  the  data  col 
known  precisely  why  the  Army  has  such 
of  submissions  of  CIMM  items  in  relati 
vices .  This  can  only  be  attributed  to 
visioning  actions  during  the  time  the 
to  the  Army  criteria  for  generation  of 
out  the  criteria  used  by  each  Service 
when  an  SSR  would  or  would  not  be  gene 
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The  Air  Force  and  Navy  submissions  are 
heavily  dominated  by  a  few  activities.  SPCC  in  the  Navy  accounted 
for  75%  of  Navy  SSRs  while  SMALC  submitted  53%  and  URALC  accounted 
for  20%  of  the  Air  Force  submissions.  The  dominance  of  Sacramento 
and  Warner  Robins  in  the  Air  Force  can  be  attributed  to  their  mis¬ 
sion  assignments  at  the  time  of  the  data  collection.  These  two 
activities  were  responsible  for  class  and  weapons  system  assign¬ 
ments  that  resulted  in  more  provisioning  actions.  Air  Force 
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GROSS  LISSR  VOLUMES  FROM  SICC  TO  CIMM 
(Request  DIC  and  %  of  Column  Total  by  Submitter) 


DIC  | 

Submitter 

CXA  X 

CXB  % 

CXC  % 

Total  Z 

ARRCOM 

0.1% 

0.3% 

3.2% 

0.2% 

CERCOM 

2.2 

2.5 

2.7 

2.3 

MIRCOM 

0.8 

0.4 

2.1 

0.6 

TARCOM 

0.8 

1.3 

0.0 

1.0 

TSARCOM 

6.0 

3.5 

0.0 

4.8 

Army 

9.9% 

8.0% 

8.0% 

8.9Z 

ASO 

4.9% 

12.7% 

2.1% 

8.6% 

SPCC 

39.7 

9.9 

3.2 

25.6 

Navy 

44.6% 

22.6% 

5.3% 

34.2% 

OCALC 

0.3% 

0.3% 

0.0% 

0.3% 

OOALC 

0.9 

2.8 

3.7 

1.8 

SAALC 

7.6 

12.5 

0.0 

9.9 

SMALC 

17.0 

30.2 

70.2 

23.4 

WRALC 

4.7 

13.4 

0.0 

8.8 

Air  Force 

30.5% 

59.2% 

73.9% 

44.2% 

MCLSBL 

6.0% 

4.2% 

5.9X 

5.2% 

MC 

6.0% 

4.2% 

5.9% 

5.2% 

EGICP 

ra 

0.0% 

0.0% 

0.2% 

SICP 

■n 

0.0 

0.0 

0.1 

A1CP 

0.0 

0.0 

0.0 

0.0 

CG 

0.7% 

0.0% 

0.0% 

0.3% 

Other 

8.3% 

6.0% 

6.9% 

7.2% 

Total 

100.0% 

100.0% 

100.0% 

100.0% 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-18 
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GROSS  LISSR  VOLUMES  FROM  SICC  TO  CIMM 
(Request  DIC  and  X  of  Row  Total  by  Submitter) 


DIG 


Submitter 

CXA  X 

CXB  X 

CXC  X 

ARRCOM 

17. 8% 

79. 6X 

2.6X 

CERCOM 

48.6 

51.2 

0.2 

MIRCOM 

71.2 

28.3 

0.6 

TARCOM 

39.4 

60.6 

0.0 

TSARCOH 

65.3 

34.7 

0.0 

Army 

57. 3% 

*- 

to 

# 

O' 

N 

0.1Z 

ASO 

29. 8X 

70. IX 

— 

spec 

81.5 

18.5 

HBHI 

68. 5X 

31.52 

O.OX 

OCALC 

48. IX 

51.92 

mm 

OOALC 

25.8 

73.8 

SAALC 

40.1 

59.9 

u  1 

SMALC 

38.1 

61.4 

WRALC 

27.7 

72.3 

Air  Force 

36. IX 

63. 6X 

0.3X 

MCLS&L 

60. 8% 

39. OX 

0.22 

MC 

60. 8X 

39. OX 

0 . 22 

EG1CP 

100. OX 

0.02 

O.OX 

SICP 

100.0 

0.0 

0.0 

AICP 

100.0 

0.0 

0.0 

CG 

100. OX 

O.OX 

O.OX 

Other 

60. 3X 

39. 5X 

0.2X 

Total 

52. 32 

47. 62 

0.2X 

Source:  DODSSK  Data  Collection;  Steady  State 


Population 


policy  at  the  time  of  the  data  collection  was  to  require  submis¬ 
sion  of  SS&s  by  the  class  or  residual  manager  as  opposed  to  the 
weapons  systems  manager.  This  has  since  been  changed  to  provide 
for  submission  of  SSRs  by  the  equipment  manager  and  the  submis¬ 
sion  ratios  are  subject  to  change  in  the  future. 

The  high  incidence  of  the  use  of  PSCNs  by 
Sacramento  is  not  accounted  for  nor  is  it  known  how  representa¬ 
tive  the  volumes  are  for  the  Coast  Guard,  since  that  Component 
jus t  started  submitting  SSRs  during  the  data  collection  period. 
The  "Other"  row  is  made  up  primarily  by  activities  in  the  Army 
other  than  the  five  principal  Commodity  Commands. 

The  rather  low  proportion  of  Navy  of  stock  num¬ 
bered  requests  by  ASO  as  shown  in  Figure  1-19  can  be  attributed 
in  part  to  their  criteria  for  generation  of  SSRs. 

The  70/30  ratio  of  part  numbers  to  NSNs  by  ASO 
is  attributable  in  part  to  their  criteria  whereby  SSRs  are  gener¬ 
ated  for  an  NSN  item  only  when  they  are  not  currently  recorded  as 
a  user  on  the  item. 

If  it  were  not  for  ASO  in  the  Navy  and  for  the 
Air  Force  activities,  the  overall  balance  of  NSNs  to  PNs  would  be 
heavily  weighted  to  NSNs.  The  ASO  reason  was  explained  above. 

The  Air  Force  submission  of  more  part  numbers  than  NSNs  can  be 
attributed  in  part  to  the  Air  Force  criteria  for  not  submitting 
SSRs  when  a  candidate  SSR  has  a  replenishment  quantity  value  of 
less  than  $1,000  and  an  SSR  for  the  same  item  has  been  submitted 
within  the  last  two  years. 

The  principal  receivers  of  CIMM  SSRs  are  dis¬ 
played  in  the  next  two  tables.  Figure  1-20  show  that  DESC  is  the 
predominate  receiver  and  processor  of  SSRs  of  all  types:  over 
502  of  the  stock  and  part  numbered  items  and  almost  99X  of  the 
PSCN  items.  DISC  is  the  next  highest  receiver  with  DCSC  and  DGSC 
roughly  equivalent. 

The  ratio  of  stock  and  part  numbered  transac¬ 
tions  among  DLA  centers  is  fairly  consistent  and  commensurates 
with  the  overall  totals  of  52  i*td  48  percent  projected  under 
population  volumes  listed  in  Figure  1-21.  The  ratios  for  GSA 
and  TARCOM  are  noticeably  different  from  the  system  totals. 
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GROSS  LISSR  VOLUMES  FROM  SICC  TO  CIMM 


(Request  DIC  and  X  of  Column  Total  by  Receiver) 


Total 


1  Die  i 

CXA  X 

CXB  % 

CXC  % 

Total  % 

9.0% 

9.9% 

0.0% 

9.4% 

55.3 

52.4 

98.9 

54.1 

8.7 

11.4 

1 . 1 

10.0 

24.0 

22.4 

0.0 

23.2 

97.0% 

96.1% 

100.0% 

96.7% 

1.6% 

3.4% 

N 

O 

• 

o 

2.4% 

0.5% 

0.1% 

o 

• 

o 

0.3% 

0.9% 

0.4% 

o 

o 

0.6% 

100.0% 

100.0% 

100.0% 

100.0% 

Population 


Figure  1-20 


The  mix  of  types  of  requests  by  receiver  is 
shown  by  Figure  1-21. 

GROSS  LISSR  VOLUMES  FROM  SICC  TO  CIMM 


(Request  DIC  and  %  of  Row  Total  by  Receiver) 


DIC 

Receiver 

CXA  % 

CXB  % 

CXC  % 

DCSC 

50.0% 

50.0% 

mm 

DESC 

53.6 

46.1 

H| 

DGSC 

45.5 

54.5 

KltS 

DISC 

54.0 

46.0 

0.0 

DLA 

52.5% 

47.3% 

0.2% 

GSA 

33.4% 

66.6% 

0.0% 

TARCOM 

86.0% 

14.0% 

0.0% 

Other 

72.6% 

27.4% 

0.0% 

Total 

52.3% 

47.6% 

0.2% 

Source:  DODSSR  Data  Collection;  Steady 

State  Population 

Figure  1-21 


(b)  WIMM 


The  proportions  of  submissions  of  VilHM  items  by 
Service  as  shown  in  Figure  1-22  is  similar  to  the  pattern  for  C1MM 
items,  with  the  Marine  Corps  slightly  higher  and  Navy  slightly 
lower.  However,  the  Navy's  ASO  is  the  predominant  submitter  of 
WIMM  SSRs  in  the  Navy.  The  submission  of  WIMM  SSRs  is,  however, 
somewhat  clouded  by  the  use  of  CIMM  document  identifier  codes  for 
WIMM  items. 

GROSS  LISSR  VOLUMES  FROM  SICC  TO  WIMM 
(Request  DIC  and  X  of  Column  Total  by  Submitter) 


DIC  ) 

Submitter 

WXA  X 

WXB  % 

wxc  % 

Total  % 

ARRCOM 

0.9% 

4.8% 

0.0% 

0.9% 

CERCOM 

2.3 

0.0 

0.0 

2.3 

M1RC0M 

2.0 

0.0 

0.0 

1.9 

TARCOM 

0.5 

0.0 

0.0 

0.5 

TSARCOM 

7.2 

33.3 

0.0 

7.5 

Army 

12.9% 

38.1% 

6* 

o 

o 

13.1% 

ASO 

28.7% 

0.0% 

0.0% 

28.7% 

SPCC 

0.2 

0.0 

0.0 

0.2 

Navy 

28.9% 

0.0% 

0.0% 

28.9% 

OCALC 

0.0% 

0.0% 

0.0% 

0.0% 

OOALC 

0.5 

0.0 

0.0 

0.5 

SAALC 

8.7 

0.0 

0.0 

8.6 

SMALC 

18.7 

0.0 

0.0 

18.5 

WRALC 

15.9 

0.0 

0.0 

15.7 

Air  Force 

43.8% 

O 

• 

o 

o 

• 

o 

43.3% 

MCLSBL 

11.4% 

61.9% 

o 

• 

o 

M 

00 

• 

rW 

MC 

11.4% 

61.9% 

© 

• 

© 

11.8% 

EGICP 

0.0% 

0.0% 

0.0% 

0.0% 

SICP 

0.3 

0.0 

0.0 

0.3 

AICP 

0.4 

0.0 

0.0 

0.4 

CG 

0.7% 

o 

• 

O 

0.0% 

0.7% 

Other 

2.3% 

o 

• 

o 

w 

o 

• 

o 

2.2% 

Total 

100.0% 

100.0% 

100.0% 

100.0% 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-22 
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Figure  1-23  confirms  the  low  usage  of  part  num¬ 
bered  SSRs  for  WIMM  items.  It  is  interesting  to  note  than  neither 
the  Air  Force  nor  Navy  submitted  any  part  numbered  SSRs  during  the 
sample  period.  However,  this  is  consistent  with  the  total  popu¬ 
lation  of  data  collected  since  the  percentage  for  part  numbers  in 
the  total  population  for  Navy  was  0.1%  and  0.5%  for  Air  Force. 

GROSS  LISSR  VOLUMES  FROM  S1CC  TO  WIMM 


(Request  DIC  and  %  of  Row  Total  by  Submitter) 


Submitter  I  WXA  % 


ARRCOM 

CER.OM 

MIRCOM 

TARCOM 

TSARCOM 


ASO 

SPCC 


OCALC 

OOALC 

SAALC 

SMALC 

WRALC 


95.9 


97.3% 


100.0% 

100.0 


100.0% 


0.0% 

100.0 

100.0 

100.0 

100.0 


DIC 


WXB  % 


4.8% 
0.0 
0.0 
.0 
.1 


Air  Force  100.0% 


MCLSBL 


EGICP 

SICP 

AICP 


Other 


Total 


95.2% 


95.2% 


0.0% 

100.0 

100.0 


100.0% 


100.0% 


99.1% 


Source:  DODSSR  Data  Collection;  Steady  State 

Population 


Figure  1-23 


in  Figure  1-24 


The  principal  receivers  of  WIMM  SSRs  are  shown 


GROSS  LISSR  VOLUMES  FROM  SICC  TO  WIMM 
(Request  DIC  and  %  of  Column  Total  by  Receiver) 


DIC  “1 

Receiver 

WXA  Z 

WXB  % 

wxc  % 

Total  % 

ARRCOM 

3.4% 

57.1% 

0.0% 

3.9% 

CERCOM 

13.0 

38.1 

0.0 

13.2 

M1RC0M 

3.7 

0.0 

0.0 

3.7 

TARCOM 

10.0 

4.8 

0.0 

10.0 

TSARCOM 

4.2 

0.0 

0.0 

4.1 

Army 

34.3% 

100.0% 

0.0% 

34.9% 

ASO 

13.6% 

0.0% 

0.0% 

13.5% 

SPCC 

20.4 

0.0 

0.0 

20.2 

warn 

34.0% 

0.0% 

0.0% 

33.7% 

OCALC 

3.7% 

0.0% 

0.0% 

3.7% 

OOALC 

3.6 

0.0 

0.0 

3.5 

SAALC 

7.1 

0.0 

0.0 

7.0 

SMALC 

3.3 

0.0 

0.0 

3.3 

WRALC 

7.7 

0.0 

0.0 

7.6 

Air  Force 

25.4% 

0.0% 

0.0% 

25.1% 

MCLSBL 

3.9% 

0.0% 

0.0% 

3.9% 

MC 

3.9% 

o 

• 

o 

N 

0.0% 

3.9% 

Other 

-a- 

• 

N 

0.0% 

0.0% 

2.4% 

Total 

100.0% 

100.0% 

100.0% 

100.0% 

Source:  DOUSSR  Data  Collection;  Steady  State  Population 


Figure  1-24 

The  receipt  of  NSN  SSRs  is  fairly  well  split  up 
among  the  Army,  Navy  and  Air  Force  in  the  steady  state  population, 
which  is  representative  of  the  entire  data  collection  period. 

The  figures  for  part  number  items  although  representative  for 
Army  and  Air  Force  indicate  no  part  number  SSRs  for  Navy.  Part 
number  SSRs  for  WIMM  items  are  heavily  affected  by  when  joint 
provisioning  actions  occur.  The  Navy  did  receive  308  part  number 
SSRs  during  the  first  half  of  the  data  collection  period.  The 


population  of  part  number  SSRs  for  WIMM  items  is  so  small  that 
any  concentration  of  the  pres,  'nee  or  absence  of  them  during  a 
particular  period  tends  to  distort  the  overall  picture  of  their 
occurrence . 


Figure  1-25  is  displayed  merely  to  confirm  the 
wide  variability  and  low  usage  of  part  numbered  SSRs  for  WIMM 
items . 


GROSS  LISSR  VOLUMES  FROM  SICC  TO  WIMM 
(Request  DIC  and  %  of  Row  Total  by  Receiver) 


Die  :  ~i 

Receiver 

WXA  % 

WXB  % 

WXC  % 

ARRCOH 

86 . 5% 

13.5% 

0.0% 

CERCOM 

97.3 

2.7 

0.0 

M1RC0M 

100.0 

0.0 

0.0 

TARCOM 

99.6 

0.4 

0.0 

TSARCOM 

100.0 

0.0 

0.0 

Army 

97.4% 

2.6% 

a* 

o 

• 

o 

ASO 

100.0% 

0.0% 

0.0% 

SPCC 

100.0 

0.0 

0.0 

Navy 

100.0% 

a* 

o 

• 

o 

a* 

o 

• 

o 

OCALC 

100.0% 

0.0% 

0.0% 

OOALC 

100.0 

0.0 

0.0 

SAALC 

100.0 

0.0 

0.0 

SMALC 

100.0 

0.0 

0.0 

WRALC 

100.0 

0.0 

0.0 

Air  Force 

100.0% 

a* 

O 

• 

o 

N 

o 

o 

MCLSBL 

100.0% 

0.0% 

a* 

o 

• 

O 

MC 

100.0% 

O 

• 

o 

a* 

o 

• 

o 

Other 

100.0% 

0.0% 

N 

O 

* 

o 

Total 

99.1% 

0.9% 

0.0% 

Source:  DODSSR  Data  Collection;  Steady  State 

Population 


Figure  1-25 


c .  Catalog  Transactions 

Catalog  transactions  may  accompany  a  request  transac¬ 
tion  to  provide  additional  technical  or  catalog  type  data.  Figure 
1-26  indicates  the  ratio  of  the  different  types  of  catalog  cards 
to  request  transactions.  Catalog  cards  are  used  only  for  CIMM 
Items. 

RATIO  OF  CATALOG  TO  REQUEST  TRANSACTIONS 

(CIMM) 


DIC 

Title 

%  Requests 

CXF 

Item  Name 

3i.7  y 

CXG 

Add  Reference  No. 

5.2 

CXK 

Add  User 

0.2  V 

Source:  DODSSR  Data  Collection 


1/  Percentage  of  part  number  requests  only. 
2/  Used  in  joint  provisioning  only. 

Figure  1-26 


It 

when  no  techni 
requested.  Th 
the  time  that 
consistent  wit 
not  available 
ability  of  tec 
item  name  card 
available,  the 
forwarding  the 
technical  data 
element  that  i 
whether  it  is 
nical  data  its 


em  name  cards  are  required  for  part  numbered  items 
cal  data  has  been  submitted  for  the  item  being 
e  31. 7%  frequency  indicates  the  relative  percent  of 
technical  data  was  not  provided.  This  is  not  in¬ 
ti  the  34%  of  the  time  technical  data  was  reported 
in  Figure  1-127,  using  the  code  to  advise  nonavail- 
hnical  data.  However,  some  of  the  systems  generate 
s  when  the  SSR  is  generated.  If  technical  data  is 
procedures  require  the  card  to  be  pulled  prior  to 
SSR.  Sometimes  the  card  is  not  pulled  even  though 
is  supplied.  The  item  name  is  a  critical  data 
s  needed  to  obtain  a  stock  number,  regardless  of 
obtained  from  an  item  name  card  or  from  the  tech- 
elf  . 


Add  Reference  Number  cards  may  be  submitted  at  the 
option  of  the  submitting  activity.  The  CXG  cards  are  sometimes 
submitted  for  stock  numbered  items  that  already  have  the  addi¬ 
tional  reference  number  recorded  on  the  Federal  Catalog  Files. 
Additional  reference  numbers  submitted  are  not  generally  re¬ 
searched  by  the  submitting  activity  prior  to  submission.  Receiv¬ 
ing  activities  will  screen  the  additional  number  with  DLSC  and 
add  the  item  if  a  match  is  made.  If  no  DLSC  match  is  found,  the 
item  will  generally  be  added  unless  there  is  something  in  the 
technical  data  supplied  by  the  submitter  that  indicates  that  the 
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item  is  a  different  item  of  supply.  The  presumption  is  made  that 
the  additional  reference  number  is  good  unless  there  is  something 
to  the  contrary  found  in  the  technical  data  supplied  by  the  sub¬ 
mitter.  Based  upon  the  low  usage  of  the  CXG,  the  lack  of  screen¬ 
ing  on  the  part  of  the  submitter,  and  the  presumption  of  validity 
on  the  part  of  the  receiving  activity,  the  CXG  transaction  should 
be  considered  for  elimination  entirely,  or  the  reference  number 
data  element  should  be  merged  with  another  transaction. 

The  CXK  Add  User  transaction  is  only  used  during  joint 
provisioning  actions.  The  extremely  low  usage  rate  does  not  ap¬ 
pear  to  justify  a  separate  transaction  to  convey  this  information. 
This  transaction  should  be  considered  for  elimination.  The  add 
user  action  could  be  taken  by  the  S1CC  directly  with  DLSC  (since 
the  add  user  action  is  taken  automatically  by  the  IMM  anyway)  or 
this  data  element  could  be  merged  in  with  another  transaction 
type. 


Figures  1-27  and  1-28  show  the  breakdown  of  the  sub¬ 
mission  of  catalog  transactions  by  submitter  and  receiver. 

(1)  Submitter.  The  submission  of  any  of  the  types 
of  catalog  cards  can  vary  significantly  by  activity  and/or  period 
of  time.  The  frequency  of  usage  is  affected  by  the  system  and 
procedures  of  the  Services  and  by  particular  activities  within  a 
Service  as  well.  The  data  in  the  figure  is  based  upon  the  steady 
state  period.  For  any  other  period  for  a  particular  activity  the 
percentage  could  vary.  However,  the  overall  percentages  for  the 
total  system  shown  in  Figure  1-26  above  are  quite  stable. 

( 2 )  Receiver 

The  data  for  catalog  cards  by  receiver  shown  in 
Figure  1-28  are  somewhat  reflective  of  the  volumes  of  SSRs  re¬ 
ceived  by  the  Components.  The  8.2X  of  the  total  for  GSA  is  much 
higher  than  the  2.4%  of  the  total  requests  received  by  GSA  as 
shown  in  Figure  1-20.  However,  GSA  does  receive  a  greater  number 
of  part  numbered  requests  66. 6%  than  the  system  total  of  47. 6% 
shown  in  Figure  1-21.  In  addition,  GSA  indicated  during  field 
research  that  the  lack  of  receipt  of  technical  data  was  a  major 
problem. 


The  number  of  CXG  and  CXK  cards  are  so  small  and 
vary  so  much  by  time  period  and  submitting  activity  that  it  is 
difficult  to  draw  any  conclusions  on  an  activity  or  Service  basis; 
however,  the  statistics  for  these  transactions  are  fairly  stable 
in  any  period  when  considered  on  a  total  system  basis. 
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L1SSR  VOLUMES  FROM  SICC  TO  C1MM 


(Catalog  D1C  and  %  of  Colunn  Total  by  Subaitter) 


Submitter  I  CXF  X 


ARRCOM 

CERCOK 

M1RC0M 

TARCOM 

TSARCOM 


0.0% 

3.6 

0.2 

1.2 

10.6 


CXG  Z 


0.0Z 

1.4 

0.9 

3.3 

0.4 


CXK  Z 


0.0% 

13.3 

0.0 

0.2 

0.2 


Total  Z 


ASO 

SPCC 


15.6% 


6.2% 

24.1 


30.3% 


13.7% 


26.8% 

29.0 


55.8% 


13.1% 


11.3% 

25.0 


36.3% 


OCALC 

OOALC 

SAALC 

SMALC 

WRALC 


0.0% 

6.2 

10.5 

9.9 

18.3 


0,0% 

0.0 

6.8 

0.1 

6.5 


0.0% 

0.0 

0.0 

26.6 

0.0 


0.0% 

4.5 

9.4 

7.7 

15.0 


Air  Force  I  44.9% 


MCLSBL 


13.4% 


26.6% 


36.6% 


Other 


Total 


100.0% 


Source:  DODSSR  Data 


100.0%  100.0%  100.0% 


Collection;  Steady  State  Population 
Figure  1-27 


LISSR  VOLUMES  FROM  SICC  TO  CIMM 
( Catalog  DIC  and  %  of  Column  Total  by  Receiver ) 


DIC  _ ! 

Receiver 

CXF  % 

CXG  % 

CXK  % 

Total  % 

DCSC 

16.7% 

13.8% 

8.3% 

15 . 8% 

DESC 

32.1 

54.5 

55.7 

38.1 

DGSC 

12.0 

11 . 2 

12 . 6 

11.8 

DISC 

27.6 

19.6 

23.2 

25.5 

DLA 

00 

00 

• 

** 

99.1% 

99.8% 

91.2% 

GSA 

8.2% 

0.8% 

0.0% 

6.2% 

TARCOM 

0.1% 

0.1% 

0.0% 

0.1% 

Other 

3  .  3% 

0.0% 

0.2% 

2.5% 

Total 

100.0% 

100.0% 

100.0% 

100.0% 

Source:  DODSSR  Data  Collection;  Steady  State 


Population 


Figure  1-28 


d.  Line  Item  Advice  Transactions 


Line  Item  Advice  Cards  (LIACs)  are  used  by  both  sub¬ 
mitters  and  receivers  of  supply  support  requests  to  reflect 
actions  taken  on  Request  transactions.  The  statistics  in  this 
section  are  arrayed  by  type  of  advice  transaction  and  are  shown 
by  both  submitter  (SICC)  and  receiver  (IMM).  Since  advice  cards 
are  related  and  provide  information  on  request  transactions  the 
use  of  submitter  in  the  tables  relates  to  the  submitter  of  the 
request  transaction  not  the  advice  transaction.  The  same  is  true 
for  the  use  of  receiver;  this  means  the  receiver  and  processor  of 
the  request  transaction  not  the  receiver  of  the  advice. 

There  is  only  one  series  of  document  identifier  codes 
for  advice  transactions  for  both  CIMM  and  WIMM  items.  Both  CIMM 
and  WIMM  LIACs  are  shown  together;  however,  except  for  TARCOM  and 
DISC,  CIMM  and  WIMM  counts  can  be  determined  by  activity  and 
volume  relationships.  TARCOM  is  the  only  Service  with  a  CIMM 
mission  and  DISC  is  the  only  Center  with  a  WIMM  mission. 

( 1 )  CXI  Advice  Transactions 


Figure  1-29  shows  the  steady  state  volumes  of 
transactions.  The  volume  and  relative  proportions  for  activity 
and  Component  are  similar  to  their  respective  request  transaction 
volumes,  since  a  CXI  provides  advice  on  action  taken  on  a  request 
transaction . 
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GROSS  LI AC  VOLUMES 
(CXI  Advice  by  Submitter/ Receiver) 


Activity/ 

Submitter  (SICC) 

Receiver 

(IMM) 

Component 

Number 

Percent 

Number 

Percent 

ARRCOM 

164 

0.2% 

81 

0.1% 

CERCOM 

1,797 

2 . 1 

260 

0.3 

MIRCOM 

647 

0.8 

41 

0.0 

TARCOM 

1,201 

1.4 

98 

0.1 

TSARCOM 

3,957 

4.6 

36 

0.0 

Army 

7,766 

9.1% 

mam 

0.5% 

ASO 

4.7% 

683 

0.8% 

SPCC 

32.5 

318 

0.4 

Navy 

31,804 

37 .2% 

1,001 

1.2% 

OCALC 

386 

0.5% 

11 

0.0% 

OOALC 

392 

0.5 

52 

0.1 

SAALC 

8,751 

10.2 

106 

0.1 

SMALC 

17,387 

20.4 

42 

0.0 

WRALC 

5 ,709 

6.7 

144 

0.2 

Air  Force 

38.3% 

355 

0.4% 

MCLSBL 

5,871 

ON 

• 

NO 

56 

0.1% 

MC 

5,871 

6.9% 

56 

0.1% 

EG1CP 

260 

0.3% 

0 

0.0% 

SICP 

137 

0.2 

2 

0.0 

AICP 

13 

0.0 

1 

0.0 

CG 

410 

0.5% 

3 

0.0% 

DCSC 

0 

0.0% 

10,771 

12.6% 

DE  SC 

490 

0.6 

42,002 

49.2 

DGSC 

127 

0.1 

10,402 

12.2 

DISC 

28 

0.0 

19,436 

22.8 

DLA 

645 

_  °.7%  _J 

82,611 

96.8% 

GSA 

0 

o 

• 

o 

819 

1.0% 

Other 

6,275 

7.3% 

35 

H 

O 

o 

Total 

85,396 

100.0% 

85,396 

100.0% 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-29 


The  General  Services  Administration  does  not 
submit  SSRs ,  so  naturally  there  are  no  volumes  shown  for  them  as 
a  submitter.  The  Coast  Guard  started  submitting  SSRs  during  the 
data  collection  period.  The  Coast  Guard  does  not  have  a  role  as 
an  1MM,  so  the  three  transactions  are  classified  as  error  trans¬ 
actions.  The  volumes  for  the  DLA  Centers  as  submitters  represent 
requirements  for  base  supply  operations. 

( 2 )  CX2  Reply  to  Offer  Transactions 

The  volume  of  reply  transactions  is  shown  in 
Figure  1-30.  The  system  total  number  of  reply  transactions  is 
extremely  small;  however,  the  system  total  percentage  of  offer 
transactions  approximates  5%.  The  volumes  of  reply  transactions 
also  vary  by  activity.  The  steady  state  population  is  quite 
representative  proportionately  except  for  the  Navy.  During  the 
transition  period  the  Navy  sent  13%  of  the  CX2  transactions. 

The  volume  of  offers  by  GSA  may  seem  low  as  a 
system  total,  but  it  is  consistent  with  their  low  percentage  of 
requests  received  in  comparison  with  DLA.  The  low  volume  for  the 
Services  as  receivers  is  consistent  with  the  high  incidence  of 
stock  numbered  requests  for  WIMM  items  and  the  low  Incidence  of 
offers  on  stock  numbered  items. 

( 3 )  CX3  Followup  Transactions 

Followup  transactions  are  sent  from  a  S1CC  to  an 
1 MM  when  the  SICC  has  not  received  advice  on  a  previous  request. 
Figure  1-31  displays  the  number  and  percent  of  followups  sent  and 
received  during  the  steady  state  period.  Followups  are  shown  for 
both  CIMM  and  WIMM  items  together. 

The  data  is  consistent  with  data  for  the  entire 
data  collection  period  except  for  the  Air  Force.  During  the 
first  half  of  the  data  collection  period,  the  Air  Force  sent  over 
86%  of  all  the  followups.  Part  of  the  reason  for  this  is  that 
the  Air  Force  sent  a  followup  for  any  suspense  record  that  was 
not  complete  at  the  time  of  the  conversion  to  the  new  system. 

The  73%  followup  submission  rate  during  the  steady  state  period 
is  still  significantly  high  when  compared  to  the  other  submit¬ 
ters.  This  is  attributable  in  part  to  the  Air  Force  system 
design  for  creation  of  the  Date  of  Request  (DOR).  The  DOR  is 
created  by  the  computer  on  the  date  the  SSR  is  generated.  The 
SSR3  then  are  sent  to  functional  area  for  matching  with  technical 
data  for  ,part  numbered  items  and  for  packaging  and  mailing  of  all 
SSRs.  The  followup  is  generated  40  days  for  NSN  items  and  73 
days  for  part  numbered  items  after  the  DOR,  if  the  SSR  is  not 
listed  as  complete  in  the  suspense  file.  The  time  to  select  draw¬ 
ings  and  mail  the  SSRs  coupled  with  the  mail  time  and  the  23-day 
process  time  allowed  the  SSR  Procedures  frequently  exceed  the 
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GROSS  L1AC  VOLUMES 


(CX2  Reply  Co  Offer  by  Submitter /Receiver ) 


Submitter 


Number  Percent 


ARRCOM 

CERCOM 

MIRCOM 

TARCOM 

TSARCOM 


100. OX 


Source:  DODSSR  Data  Collection;  Steady  State  Population 

Figure  1-30 


GROSS  L1AC  VOLUMES 

(CX3  Followup  by  Submitter/Receiver) 


Activity/ 

Submitter  (SICC) 

Receiver 

(IMM) 

Component 

Number 

Percent 

Number 

Percent 

ARRCOM 

22 

0.2% 

86 

0.8% 

CERCOM 

0 

0.0 

32 

0.3 

MIRCOM 

0 

0.0 

16 

0.1 

TARCOM 

14 

0.1 

70 

0.6 

TSARCOM 

8 

0.1 

48 

0.4 

Army 

44 

0.4% 

252 

2.2% 

ASO 

2,875 

■M 

199 

1.8% 

SPCC 

0 

HH 

294 

2.6 

Navy 

2,875 

25.3% 

493 

4.4% 

OCALC 

0.0% 

55 

0.5% 

OOALC 

5.8 

47 

0.4 

SAALC 

HSbH 

18.3 

64 

0.6 

SMALC 

. 

29.7 

18 

0.2 

WRALC 

19.5 

50 

0.4 

Air  Force 

8,328 

73.3% 

234 

mm 

MCLSBL 

72 

0.6% 

42 

0.4% 

MC 

72 

0.6% 

42 

0.4% 

EGICP 

0 

0.0% 

0 

0.0% 

SICP 

0 

0.0 

2 

AICP 

0 

0.0 

0 

0.0 

CG 

0 

0.0% 

2 

0.0% 

0 

mem 

597 

5.3% 

0 

5,008 

43.9 

DGSC 

0 

337 

3.0 

DISC 

0 

3,691 

32.5 

DLA 

0 

0.0% 

9,633 

84.7% 

GSA 

0 

0.0% 

678 

6.0% 

Other 

40 

0.4% 

25 

0.2% 

Total 

100.0% 

100.0% 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-31 
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35-day  timeframe  allowed  by  the  procedures  on  which  the  followups 
are  based;  therefore,  there  Is  not  always  sufficient  time  allowed 
to  permit  an  advice  transaction  to  be  received  from  the  IMM.  The 
followup  procedures  in  the  automated  systems  in  the  Army  and  Navy 
allow  about  two  weeks  to  permit  the  selection  of  drawings  and 
mailing  of  SSRs. 


The  data  for  receipt  of  followups  generally  ap¬ 
pears  to  match  the  volume  of  requests  from  C1MM  items.  However, 
the  volume  of  followups  for  DISC  and  GSA  are  significantly  higher 
than  the  proportion  of  requests  that  they  received.  WIMM  requests 
account  for  0.2%  of  the  combined  total  of  CIMM  and  WIMM  requests; 
however,  the  number  of  followups  for  WIMM  items  was  approximately 
9%  of  the  total.  The  relation  of  followups  to  responses  is  dis¬ 
cussed  in  the  next  section.  The  relation  of  followups  to  trans¬ 
mission  and  processing  times  and  to  delinquency  rates  is  discussed 
in  the  life  cycle  network  analysis  later  on  in  this  Chapter. 

(4)  CX4  Response  to  Followup  Transactions.  Responses 
to  followups  are  required  to  be  provided  by  the  IMM  within  15 
days  after  the  receipt  of  a  followup.  The  proportions  of  re¬ 
sponses  in  Figure  1-32  will  not  necessarily  match  precisely  the 
proportions  of  followups  in  Figure  1-31  due  to  the  cutoff  for 
the  data  collection  and  the  varying  procedures  among  the  submit¬ 
ters  and  receivers  of  SSRs  for  the  use  of  automated  processing 
and  AUTODIN  transmission  for  L1AC  transactions.  Response  trans¬ 
actions  are  shown  here  to  depict  the  relative  volumes  in  relation 
to  requests  and  followups.  The  volume  data  shown  here  also  pro¬ 
vides  a  basis  for  further  analysis  under  Action  Taken  Code  Anal¬ 
ysis  and  the  Life  Cycle  Network  Analysis. 

4.  Advice  Analysis.  Line  Item  Advice  Cards  (LIACs)  are  used 
by  both  submitters  and  receivers  of  SSRs  to  reflect  actions  taken 
on  request  transactions.  Types  of  LIACs  and  advice  categories 
were  discussed  in  detail  in  Chapter  IV,  Volume  I.  There  are  70 
different  Action  Taken  Codes  listed  in  Appendix  E  of  the  SSR 
Procedures.  An  Action  Taken  Code  (ATC)  is  a  two-character  alpha¬ 
betic  or  numeric  code  to  identify  advice  being  provided  in  LIACs. 
The  ATCs  are  used  in  CXI,  CX2 ,  and  CX4  advice  cards.  One  of  the 
original  problems  reported  by  the  SPG  was  a  high  reject  rate  of 
SSRs.  This  section  provides  an  analysis  of  ATCs  by  category  and 
individual  ATC  to  ascertain  the  extent  and  scope  of  the  problem; 
and  to  develop  improvements  where  necessary. 

a .  Advice  Categories 

The  SSR  Procedures  do  not  specifically  group  advice 
codes  (ATCs)  by  category.  The  nature  of  the  advice  must  be  deter¬ 
mined  by  type  of  advice  card  in  which  it  appears,  using  the  docu¬ 
ment  identifier  code  and  the  definition  of  the  ATC  associated  with 
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GROSS  LI AC  VOLUMES 

(CX4  Response  to  Followup  by  Submitter/Receiver ) 


Activity/ 

Subaittei 

f  (SICC) 

Receiver 

(IMM) 

Coaponent 

Nuaber 

Percent 

Nuaber 

Percent 

ARRCOM 

13 

0.2X 

38 

0.6X 

CERCOM 

0 

0.0 

2 

0.0 

MIRCOM 

0 

0.0 

0 

0.0 

TARCOM 

6 

0.1 

7 

0.1 

TSARCOM 

8 

0.1 

6 

0.1 

Aray 

27 

0 . 4  X 

53 

0.8X 

ASO 

316 

4.8X 

0 

O.OX 

SPCC 

0 

0.0 

4 

0.1 

Navy 

316 

4.8X 

4 

0.1X 

OCALC 

0 

o.ox 

0 

O.OX 

OOALC 

129 

2.0 

0 

0.0 

SAALC 

1,818 

27.5 

5 

0.1 

SMALC 

2,716 

40.9 

1 

0.0 

WRALC 

1,500 

22.7 

6 

0.1 

Air  Force 

6.163 

93. IX 

12 

0.2X 

MCLSBL 

70 

1.1X 

2 

ft* 

O 

• 

o 

MC 

70 

1.1X 

2 

o.ox 

EGICP 

0 

o.ox 

0 

o.ox 

SICP 

0 

0.0 

0 

0.0 

A1CP 

0 

0.0 

o 

0.0 

CG 

0 

o.ox 

o 

o.ox 

DCSC 

0 

o.ox 

440 

6.7X 

DESC 

0 

0.0 

3,083 

46.5 

DGSC 

0 

0.0 

255 

3.9 

DISC 

0 

0.0 

2,719 

41.1 

DLA 

0 

o 

e 

o 

6,497 

98. 2X 

GSA 

0 

o.ox 

45 

0.7X 

Other 

37 

0.6X 

0 

o.ox 

Total 

6,613 

100. OX 

6,613 

100. OX 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-32 
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the  document  Identifier  code.  The  number  of  the  advice  codes  (70) 
and  the  definitions  have  been  confusing  to  submitters  and  receivers 
of  SSRs  in  attempting  to  categorize  the  type  of  advice  being  re¬ 
ceived.  This  is  particularly  true  in  attempting  to  classify  an 
item  as  being  initially  accepted,  finally  accepted,  rejected  due 
to  a  validation  error,  rejected  due  to  improper  FSC  or  manager  as¬ 
signment  or  for  other  reasons.  The  study  team  performed  an  anal¬ 
ysis  of  the  codes  and  the  definitions  and  grouped  the  codes  into 
logical  categories  in  order  to  generate  reports  and  analyze  the 
types  of  advice  being  provided.  Figure  1-33  groups  the  ATCs  into 
five  major  categories.  Because  of  the  large  number  of  codes,  the 
Reject  Category  is  further  broken  down  into  logical  subgroups. 

ATC  CATEGORIZATIONS 


Individual  ATCs 

Number 

ATCs 

Percent 

Total 

Accept 

YA,  YB,  YD,  YE,  YX 

5 

7.1 

Offer 

YL,  YQ 

2 

■■BDI 

Pending 

64,  67  ,  99  J J 

3 

2791 

Reject 

■ 

-  FSC/Manager 

YC,  YK,  03,  11,  17,  41,  60,  63 

8 

-  NSN/PSCN 

YH,  YJ,  YR,  YU,  YW,  33,  34,  35, 

45,  62,  68 

11 

Sllllf 

-  Catalog/Tech- 

YS,  02,  09,  13,  14,  19,  21,  44 

nical  Data 

70 

9 

-  Invalid  Data 

01,  04,  05,  07,  18,  23,  24,  25, 

28,  30,  31,  32,  38,  39,  40,  52, 

56,  59 

27.0 

-  Match/Dup 

42,  51,  58,  66  2/ 

5.7 

-  Procurement 

12,  20,  22 

4.3 

-  Other 

08,  36,  57 

4.3 

Total  Rejects 

57 

81.3 

Replies  to 

mmmmm 

Offers 

i—l 

-  Accept 

YM,  YV 

2 

-  in 

-  Reject 

YP,  YN 

2 

Total  Replies 

to  Offer 

4 

5.8 

Grand  Total 

Source:  SSR  Procedures 


/  ATC  99  established  for  AUTODIN  Test  only. 

/  ATC  66  used  only  on  CX4  responses. 

/  Pending  total  is  2  and  grand  total  is  70  when  ATC  99  is 
excluded . 


Figure  1-33 
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SSR  submitters  and  receivers  complained  during  field 
research  about  the  number  of  different  ATCs  and  their  definitions, 
indicating  that  they  had  a  difficult  time  understanding  the  dif¬ 
ferent  types  of  advice.  They  appeared  to  be  particularly  con¬ 
fused  over  the  question  of  when  an  SSR  was  accepted  and  when  it 
was  rejected;  and  whether  the  SSR  was  rejected  for  validation  or 
action  reasons.  They  could  not  understand  why  there  were  so  many 
reject  codes  as  compared  to  those  for  acceptance. 

Figure  1-34  summarizes  the  ATCs  in  Figure  1-33  Into  the 
relative  proportion  for  each  of  the  major  categories. 


ATC  PROPORTIONS 


Source:  SSR  Procedures,  Appendix  E 


Figure  1-34 
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This  pie  chart  dramatically  depicts  the  overwhelming 
number  of  ATCs  available  to  be  assigned  to  reject  a  supply  sup¬ 
port  request  (81. 3X)  as  compared  with  ATCs  available  to  be  as¬ 
signed  to  accept  a  request  (7. IX).  It  must  be  emphasised  that 
these  are  the  codes  that  are  available  to  be  assigned  and  do  not 
reflect  the  actual  percentages  of  acceptances  and  rejects  that 


occur  in  practice. 


The  categorizations  in  Figure  1-33  were  used  in  tables 
in  computer  programs  to  generate  reports  to  show  the  actual 
occurrence  of  the  different  categories  of  ATCs  and  of  Individual 
ATCs.  The  results  of  this  analysis  are  shown  below. 

(1)  Cl MM 

(a)  Submitter/  S1CC 

The  statistics  shown  in  this  section  were 
derived  from  the  transactions  submitted  during  the  DODSSR  Data 
Collection.  CXI,  CX2  and  CX4  advice  transactions  were  matched  up 
with  their  respective  request  transactions  using  control  data  ele¬ 
ments.  This  was  done  to  determine  if  there  was  any  difference  in 
patterns  for  NSN,  part  number  and  permanent  system  control  number 
requests.  The  request  and  advice  transactions  were  further  iden¬ 
tified  to  the  activities  submitting  the  request  (submitter /SICC ) 
and  those  receiving  the  request  but  submitting  the  advice  (Re- 
ceiver/IMM).  The  table  shown  in  Figure  1-33  was  used  to  cate¬ 
gorize  advice  and  to  compute  percentages.  Category  percentages 
were  computed  by  dividing  the  number  of  occurrences  in  the  cate¬ 
gory  by  the  row  total  of  occurrences  for  all  categories.  The 
percent  of  the  category  allocable  to  Individual  activities  or 
Components  was  also  computed  by  dividing  the  activity  or  Compo¬ 
nent  occurrence  for  the  category  by  the  column  total  for  all 
activities  for  the  particular  category.  Reports  showing  the 
category  percentage  to  total  of  all  categories  (row  totals)  will 
generally  be  shown  with  percentages  within  categories  narratively 
inserted. 


Figure  1-35  shows  the  advice  categories  by 
submitting  activity.  The  data  for  the  steady  state  period  was 
used  because  of  the  incidence  of  Invalid  codes  and  errors  attri¬ 
butable  to  the  conversion  from  the  old  to  new  systems.  The  Main 
Population  showed  a  62. 8Z  accept  and  a  37.25!  reject  rate  while 
the  Transition  Period  had  a  61. 7X  accept  and  38.3X  reject  rate. 
The  67. IX  accept  rate  and  32. 9X  reject  rate  for  the  Steady  State 
Population  shown  in  Figure  1-35  reflects  a  more  true  picture  of 
the  system  after  elimination  of  errors  attributable  to  the  con¬ 
version  process. 


ATC  ADVICE  ANALYSIS  BY  SICC 
(Number  and  X  of  Row  Total  for  DIC  CXA) 


Source:  DOUSSR  Data  Collection;  Steady  State 
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Figure  1-35 
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The  DOOSSR  Study  Team  does  not  consider  the 
accept  and  reject  rates  for  NSN  requests  to  be  acceptable*  If 
the  submitting  activity  were  properly  screening  the  items  with 
DLSC  and  validating  transactions  prior  to  submission,  there 
should  be  only  about  a  1%  reject  rate  for  stock  numbered  items* 

An  analysis  of  the  reject  rates  shown  later  in  this  Report  will 
indicate  some  of  the  causes  of  the  high  reject  rate  for  NSN  re¬ 
quests*  The  low  percentage  of  occurrence  for  offers  and  pending 
advice  is  considered  acceptable  for  NSN  items;  these  rates  were 
consistent  throughout  the  data  collection. 

Advice  for  part  numbered  requests  is  shown 
in  Figure  1-36*  The  percentages  for  acceptance  were  within  IX 
of  the  Main  and  Transition  Period  Populations.  Rejections  were 
five  to  six  percent  higher  during  the  early  parts  of  the  data 
collection  due  to  conversion  to  the  new  procedures.  The  com¬ 
parison  of  the  44%  accept  rate  for  part  numbered  items  to  the  67X 
accept  rate  for  NSN  items  must  be  tempered  by  the  13X  increase  in 
the  number  of  offers  for  part  numbered  items  as  opposed  to  NSN 
items;  however,  there  is  still  an  8%  higher  rate  of  rejection  of 
part  numbered  items.  The  1.2%  pending  rate  la  attributable 
largely  to  ATC  99  which  was  established  by  the  study  group  for  a 
test  conducted  during  the  study.  If  this  code  is  subtracted,  the 
percentage  for  pending  is  less  than  one  percent.  The  reject  rate 
for  part  numbered  items  is  also  considered  intolerable.  In  addi¬ 
tion  to  the  DLSC  screening  and  validation  reasons  given  above  for 
NSN  items,  improper  formatting  of  part  numbers  and  failure  to 
provide  technical  data  contribute  to  the  part  number  reject  rate. 

The  report  for  permanent  system  control 
numbered  items  is  not  shown  due  to  the  extremely  low  usage  of 
PSCN  requests.  There  was  a  69.7%  acceptance  and  28.6%  reject 
rate  out  of  a  total  of  119  PSCN  advice  transactions  during  the 
Steady  State  Period.  Rates  for  PSCN  items  should  approximate 
those  for  NSNs  since  these  items  have  already  been  subjected  to 
standardization  actions  and  an  NSN  will  be  assigned  immediately 
upon  request. 


The  consistently  low  rate  of  less  than  one 
percent  for  the  pending  category  indicates  that  initial  advice  is 
generally  being  sent  out  within  25  days  after  the  receipt  of  the 
requests  as  recorded  by  the  receiving  IMM.  IMMs  are  required  to 
provide  initial  advice  to  requests  within  25  days  of  the  receipt 
of  a  request.  If  pending  advice  is  submitted,  advice  on  the 
supply  support  decision  must  be  provided  within  15  days  after  the 
use  of  the  pending  advice.  The  combined  offer  rate  is  relatively 
meaningless,  since  most  of  the  offers  are  made  for  part  numbered 
items.  The  combined  reject  rate  like  the  individual  rites  for 
NSN,  part  number  and  PSCN  items  is  unacceptable.  A  more  detailed 
analysis  of  accept,  offer  and  reject  categories  is  provided  later 
in  this  Chapter.  Individual  and  subcategorizations  are  used  in 
an  attempt  to  isolate  the  reasons  for  the  percentage  rates  for 
these  categories. 
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ATC  ADVICE  ANALYSIS  BY  SICC 
(Number  and  X  of  Row  Total  for  DIC  CXB) 


Acce 

jt 

Offer 

Pending 

Re; 

ect 

Total 

SICC 

No. 

% 

No. 

X 

No. 

X 

No. 

% 

No. 

X 

ARKCOM 

41 

35.3 

8 

6.9 

0.0 

67 

57.8 

116 

100.0 

CERCOM 

208 

31.1 

102 

15.2 

0.0 

359 

53.7 

669 

100.0 

MIRCOM 

95 

55.9 

16 

9.4 

0.0 

59 

34.7 

170 

100.0 

TARCOM 

246 

39.6 

9 

1.4 

0.0 

366 

59.0 

621 

100.0 

TSARCOM 

421 

35.4 

20 

1.7 

0.0 

_ 7481 

62.9 

1,189 

100.0 

1,011 

36.6 

155 

5.6 

0.0 

BO 

57.8 

100.0 

ASO 

1 

26.4 

635 

24.9 

u 

0.0 

48.7 

100.0 

SPCC 

SHIS 

56.3 

410 

6.9 

0.0 

36.8 

EH 

100.0 

mm 

4,041 

47.4 

M 

12.3 

■ 

HI 

3,440 

40.3 

8,527 

100.0 

OCALC 

32 

39.0 

i 

1.2 

0.0 

49 

82 

100.0 

OOALC 

21 

24.7 

i 

1.2 

0.0 

63 

85 

100.0 

SAALC 

2,935 

55.4 

169 

3.2 

0.0 

2,196 

41.4 

KwjiJ 

100.0 

SMALC 

3,816 

33.3 

2,755 

24.1 

442 

3.9 

4,441 

38.7 

■Hry-s 

100.0 

WRALC 

1,651 

39.3 

356 

8.5 

0.0 

2,198 

52.2 

100.0 

AF 

8,455 

40.0 

Hi 

15.5 

442 

2.1 

8,947 

42.4 

HH 

100.0 

MCLSBL 

1,728 

68.1 

202 

8.0 

0.0 

605 

23.9 

mm 

100.0 

MC 

1,728 

68.1 

202 

8.0 

0.0 

605 

23.9 

2,535 

100.0 

EG1CP 

0.0 

0.0 

■ 

0.0 

0.0 

0.0 

SICP 

0.0 

0.0 

1 1 

0.0 

0.0 

0.0 

A1CP 

0.0 

0.0 

0.0 

0.0 

0.0 

CG 

0.0 

0.0 

0.0 

0.0 

Other 

1,497 

55.7 

251 

9.3 

0.0 

942 

35.0 

100.0 

Total 

16,732 

44.4 

Hi 

13.1 

443 

1.2 

ms 

41.3 

ESS 

100.0 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-36 


The  total  for  all  requests  Is  shown  in  Figure  1-37 
for  comparison  with  those  for  NSN  and  part  numbered  items. 

ATC  ADVICE  ANALYSIS  BY  SICC 
(Summary  of  No.  and  %  of  Row  Total  for  DICs  CXA/B/C) 
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Figure  1-37 
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(b)  Recelver/IMM 


Figures  1-38  and  1-39  displays  statistics 
for  CIMM  advice  by  IMM.  TARCOH  and  GSA  have  the  highest  accep¬ 
tance  and  lowest  reject  rates  of  all  activities,  although  the 
volumes  of  advice  are  relatively  low.  Because  of  its  volume,  DLA 
dominates  the  percentages  and  the  averages  for  DLA  approximates 
the  average  totals.  However,  within  DLA  there  are  significant 
variances  from  the  averages  that  are  attributed  to  activity  dif¬ 
ferences.  Particularly  notable  are  the  acceptance  and  reject 
rates  for  DCSC  and  DGSC  with  DCSC  having  the  highest  acceptance 
rates  and  lowest  reject  rates  and  DGSC  having  the  lowest  accept 
and  highest  reject  rates  in  DLA  for  NSN  items.  The  rates  for 
TARCOM  and  GSA  are  attributed  to  the  low  volumes  and  manual  pro¬ 
cessing.  Under  such  conditions  the  receiving  activity  can  man¬ 
ually  correct  or  ignore  minor  errors  not  absolutely  essential  to 
processing.  It  is  still  notable  that  no  activity  or  Component 
has  an  accept  ratio  higher  than  90Z  or  a  reject  rate  less  than 
10Z. 

The  accept/reject  rates  for  TARCOM  are 
based  upon  too  small  a  sample  to  be  significant.  Either  TARCOM 
receives  few  part  number  requests  for  CIMM  items  or  the  items  are 
being  sent  as  WIMM  requests.  The  low  accept  and  high  reject  rate 
for  GSA  part  numbered  items  is  explainable  in  part  due  to  the 
complaint  by  GSA  during  field  research  about  the  lack  of  technical 
data.  Once  again,  DCSC  has  the  low  and  DGSC  the  high  reject 
rates  among  DLA  activities.  The  high  number  of  offers  by  DESC 
does  have  a  potential  effect  upon  its  acceptance  rate  but  would 
not  tend  to  have  an  effect  upon  its  reject  rate.  It  should  be 
noted  that  DESC  accounts  for  over  83Z  of  all  the  offers  for  part 
numbered  items.  Since  the  offer  analysis  shown  below  indicates  a 
high  rate  of  acceptance  of  offers,  this  would  tend  to  increase 
the  acceptance  rates  for  those  activities  with  a  high  percentage 
of  offers. 

Receiver  statistics  for  PSCN  items  are  not 
shown  due  the  low  volume  of  requests  for  this  type  of  item.  It 
should  be  noted;  however,  that  DESC  receives  about  90Z  of  all  the 
PSCN  items.  Acceptance  and  reject  totals  are  the  same  as  for  the 
submitter  reports. 
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Receiver  statistics  for  all  requests  for 
C1MM  items  are  shown  In  Figure  1-40.  Activity  and  Component 
averages  are  ouch  more  stable  and  similar  to  the  average  totals 
than  when  shown  separately  for  NSN  and  part  number  requests* 

When  all  requests  are  considered  TARCOM  still  has  the  lowest 
reject  rate  while  GSA  and  DLA  have  reject  rates  that  approximate 
the  average.  There  is  still  a  wide  variance  among  DLA  Supply 
Centers,  though,  with  Construction  continuing  to  have  the  lowest 
and  General  the  highest  reject  rates. 

(2)  WIMM 

(a)  Submit ter/SICC 

Advice  statistics  for  WIMM  items  are  shown 
in  Figure  1-41.  This  table  shows  counts  for  both  part  number  and 
NSN  items,  since  there  were  no  PSCN  items  for  WIMM  items  in  the 
data  collection  and  the  sample  of  part  numbered  items  alone  in 
this  sample  was  too  small  to  show  separately.  In  comparing  this 
table  with  the  CIMM  NSN  statistics,  the  81.4%  accept/17. 1%  reject 
rates  are  much  better  than  the  67.11/32.9%  rates  for  CIMM  items. 
However,  the  volume  of  traffic  for  WIMM  advice  is  only  0.4%  of 
the  CIMM/WIMM  total  advice.  Also,  WIMM  SSRs  are  generally  for 
stock  numbered  items,  are  processed  manually  and  the  only  data 
elements  in  the  SSR  generally  given  serious  consideration  for  the 
purpose  of  making  an  accept  or  reject  decision  are  the  stock  num¬ 
ber  and  the  Major  Organizational  Entity  (MOE)  Rule.  Validation 
errors  are  generally  corrected  or  ignored.  The  accept  and  reject 
rates  by  Component  approximate  the  average  totals  while  there  are 
fluctuations  by  activity  attributable  to  sample  size  and  activity 
variations . 

(b)  Recelver/IMM.  The  receiver  statistics  for 
SSR  advice  parallel  those  for  the  submitter.  The  Component  aver¬ 
ages  approach  the  system  totals  while  there  are  activity  fluctua¬ 
tions.  Figure  1-42  indicates  that  CERCOM  in  the  Army  with  a  7.3% 
reject  rate  is  the  first  indication  of  an  activity  with  a  sizable 
volume  that  has  a  reject  rate  less  than  10%.  SPCC  in  the  Navy 
has  the  highest  reject  rate.  There  are  very  few  offers  for  WIMM 
items  since  only  stock  numbered  SSRs  are  submitted  except  for 
joint  provisioning  actions.  The  number  of  part  numbered  items  is 
so  small  that  they  are  considered  together  with  NSNs  in  this 
table . 
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Figure  1-41 


ATC  ADVICE  ANALYSIS  BY  RECEIVER 
(Summary  of  No*  and  X  of  Row  Total  for  DICs  WXA/B) 
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Figure  1-42 
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Accept  Analysis 


Individual  action  taken  codes  were  reviewed  to  deter¬ 
mine  the  types  of  accept  advice  that  were  being  given,  since  the 
study  team  had  concluded  that  the  rates  of  acceptance  were  not 
satisfactory.  The  accept  category  has  five  ATCs  that  can  be  used 
to  indicate  acceptance  of  an  SSR: 

YA  -  Used  to  provide  an  MSN  notification.  May  have 
been  preceded  by  ATCs  YD,  YE  or  YX.  Could  have 
been  preceded  by  a  YB,  although  the  definition 
of  YB  seems  to  connote  that  the  YB  will  provide 
an  NSN.  May  contain  a  new  support  date  if  the 
date  repair  parts  required  cannot  be  met.  If  a 
new  support  date  is  provided  the  YA  is  used  in 
lieu  of  a  YX. 

YB  -  Advises  that  the  item  requested  in  an  SSR  is 

identified  by  an  NSN  which  is  managed  as  a  de¬ 
centralized  item  (AAC  L) .  Does  not  indicate 
whether  an  NSN  is  provided,  but  the  format 
provides  for  an  NSN  and  providing  an  NSN  is  not 
precluded . 

YD  -  Advises  that  an  item  requested  is  identified  as 
a  centrally  procured,  not  stocked  item  (AAC  J) . 

If  an  NSN  is  already  assigned,  it  may  be  provided 
in  the  advice  card  but  the  definition  does  not 
specifically  state  this.  If  the  item  does  not 
have  an  NSN  assigned,  or  assigned  but  not  pro¬ 
vided  in  the  YD  advice  card,  the  NSN  should  be 
provided  by  a  YA  advice  card.  Procurement  of 
required  quantities  contingent  upon  receipt  of 
a  funded  requisition. 

YE  -  Advises  that  the  item  requested  in  an  SSR  will 
be  supported  by  the  required  date.  If  the 
request  is  for  a  part  numbered  item,  the  YE 
should  be  followed  by  a  YA  advice  when  an  NSN  is 
obtained  for  the  item. 


Advises  acceptance  but  provides  a  new  support 
date,  since  the  date  repair  parts  required  had 
passed  or  was  less  than  procurement  lead  time 
on  the  date  the  SSR  was  received  by  the  IMM. 
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Figure  1-43  breaks  down  accept  advice  into  the  indi¬ 
vidual  types  of  accept  advice  that  may  occur.  The  data  includes 
advice  for  both  CIMM  and  W1MH  items  together.  The  Air  Force 
received  more  NSN  notifications  than  any  other  Component,  but  by 
the  same  token  the  Air  Force  submitted  more  part  numbered  requisi¬ 
tions.  Previous  charts  indicated  that  approximately  47%  of  the 
CIMM  requests  were  for  part  numbered  items  and  of  these  about  43% 
were  accepted.  It  would  appear  that  more  than  8.4%  of  the  accept 
advice  would  be  YA  NSN  notifications.  Either  NSNs  are  being  pro¬ 
vided  in  some  of  the  other  accept  advice  cards  the  advice  is  being 
lost  or  not  recorded  or  the  NSN  is  not  being  provided  through  the 
use  of  the  SSR  process. 

ACCEPT  ADVICE  ANALYSIS  BY  SUBMITTER  FOR  CIMM/WIMM 
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Figure  1-43 

The  percentage  of  YB  (decentralized)  and  YD  (central 
procure)  may  vary  from  Component  to  Component  and  from  time  to 
time  depending  upon  the  item  requested  and  the  stockage  policy  of 
the  IMM.  The  rates  for  YE  and  YX  are  interesting.  These  two 
ATCs  should  he  considered  together,  since  they  are  the  opposite 
of  each  other.  YE  indicates  that  support  will  be  provided  by  the 
date  requested  and  YX  advises  that  the  requested  support  date 
cannot  be  met  because  the  date  required  was  passed  by  the  time 
the  IMM  received  the  request  or  that  the  leadtime  for  the  item 
was  longer  than  allowed  for  by  the  date  required.  The  SSR  Proce¬ 
dures  provide  for  the  S1CC  to  submit  SSRs  as  soon  as  possible 
after  the  determination  of  the  range  and  quantity  of  support 
requirements  to  permit  the  IMM  sufficient  time  to  Identify  and 
support  the  requirements  of  the  SICC.  The  8.7%  YX  rate  for  the 
Navy  is  significantly  lower  than  those  for  the  other  Services. 

The  nearly  20%  rate  of  new  support  dates  for  the  Air  Force  and 
Marine  Corps  appears  to  be  rather  high. 


The  table  In  Figure  1-44  was  developed  to  determine 
If  the  YX  rates  were  Influenced  by  activity  factors. 

ACCEPT  ADVICE  ANALYSIS  BY  SUBMITTER  FOR  CIMM/WIMM 
(Frequency  of  Occurrence  -  Row  X) 


Accept  ATC  | 

SICC 

YE 

YX 

ARRCOM 

19.5% 

35.4% 

CERCOM 

47.8 

14.2 

MIRCOM 

75.1 

9.4 

TARCOM 

55.7 

21.6 

TSARCOH 

59.1 

11.5 

Army 

58.3% 

13.7% 

ASO 

57.1% 

11.8% 

spec 

75.0 

8.4 

Navy 

73.3% 

8.7% 

OCALC 

79.8% 

17.1% 

OOALC 

90.1 

5.3 

SAALC 

44.5 

19.7 

SMALC 

54.3 

18.3 

WRALC 

33.8 

22.0 

Air  Force 

48.4% 

19.2% 

MCLSBL 

34.8% 

19.3% 

Marine  Corps 

34.8% 

19.3% 

Other 

50.0% 

18.2% 

Total 

57.9% 

14.6% 

Source:  DODSSR  Data  Collection,  Steady  State  Population 

Figure  1-44 

On  the  basis  of  the  activity  statistics,  it  appears 
that  the  Component  data  is  influenced  by  activity  differences, 
since  there  are  wide  variations  in  the  YX  rates  for  different 
activities.  Activities  with  a  high  YX  rate  should  review  their 
provisioning  cycles  and  criteria  for  establishment  of  support 
dates  in  order  to  permit  submission  of  SSRs  early  enough  in  the 
provisioning  cycle  to  allow  enough  time  for  the  IMM  to  complete 
its  processing  cycle  and  to  provide  supply  support  by  a  realistic 
support  date- 
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Statistics  were  also  generated  for  accept  advice  by 
IMM  to  see  if  there  was  any  significant  differences  among  activi¬ 
ties  or  Components.  These  statistics  are  displayed  in  Figure 
1-45. 

ACCEPT  ADVICE  ANALYSIS  BY  RECEIVER  FOR  CIMM/WIMM 
(Frequency  of  Occurrence  -  Row  %) 


Component 

IMM 

i  Accept  ATC  \ 

YA 

YB 

YD 

YE 

YX 

Army 

o.ox 

O.OX 

4.2X 

93. 9% 

1.9X 

Navy 

0.0 

1.0 

23.1 

70.6 

5.3 

Air  Force 

0.0 

1.7 

2.4 

95.9 

0.0 

Marine  Corps 

0.0 

53.3 

46.7 

0.0 

DLA 

8.7 

0.5 

18.4 

57.4 

15.0 

GSA 

0.6 

40.4 

21.7 

37.3 

0.0 

Other 

10.0 

0.0 

26.7 

60.0 

3.3 

Total 

8.4/o 

0.8X 

N 

cn 

• 

00 

H 

57. 9X 

14. 6X 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-45 

With  the  exception  of  the  CIMM  assignment  at  TARCOH 
the  statistics  for  the  Services  are  for  WIMM  items.  The  volume 
of  activity  is  so  low  that  differences  in  the  first  three  columns 
can  be  accounted  for  on  the  basis  of  volume.  However,  the  low 
usage  of  YX  for  the  Services  and  GSA  can  be  accounted  for  based 
upon  the  policy  and  procedures  observed  during  field  research. 

As  a  general  rule,  DLA  routinely  considers  the  support  date  in 
providing  advice,  but  the  procedures  among  the  Services  and  GSA 
vary  considerably  among  and  within  Components.  The  incidence  of 
use  of  YA  NSN  advice  by  WIMMs  is  so  low  that  it  becomes  zero 
during  the  rounding  process.  The  low  rate  for  YA  for  GSA  is 
attributed  to  the  time  period  since  GSA  did  provide  a  significant 
number  of  YA  advice  during  the  first  part  of  the  data  collection. 
The  usage  of  YB  and  YD  by  GSA  is  attributed  to  GSA  policy  of  not 
stocking  items  on  the  basis  of  an  SSR.  GSA  policy  is  to  ini¬ 
tially  assign  AAC  J  (centrally  procure  -  nonstocked)  or  AAC  L 
(local  purchase).  GSA  does  not  change  the  AAC  to  stock  an  item 
until  an  actual  demand  pattern  has  developed  unless  required  by 
the  regional  manager  on  an  exception  basis. 

The  YE  and  YX  accept  advice  for  DLA  was  broken  down 
by  activity  to  see  if  there  was  any  activity  differences;  this 
information  is  displayed  in  Figure  1-46. 


a 
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ACCEPT  ADVICE  ANALYSIS  BY  RECEIVER  FOR  DSCs 
(Frequency  of  Occurrence  -  Row  X) 


IMM 

YE 

YX 

35.8% 

28.9% 

DESC 

64.0 

11.9 

DGSC 

50.3 

19.2 

DISC 

61.2 

10.6 

DLA 

47 .4X 

15.0% 

Source:  DODSSR  Data  Collection;  Steady  State 

Population 

Figure  1-46 

There  is  an  activity  variance  from  4.4%  below  the  DLA 
average  total  to  13. 9%  above  the  average  for  YX  advice.  The  YX 
support  date  is  computer  determined  based  upon  the  date  repair 
parts  required  (DRPR)  and  the  production  leadtime  in  the  SSR,  and 
the  date  the  SSR  is  received  by  the  IMM.  The  date  received  by  the 
I MM  is  the  date  the  SSRs  have  been  posted  to  the  automated  SSR 
suspense  file.  The  variances  in  YX  rates  by  IMM  are  attributed 
to  a  combination  of  short  DRPRs  and  long  leadtimes  placed  in  the 
SSR  by  the  submitter,  transmission  time  to  mail  SSR  packages  to 
the  IMM,  and  internal  wait  time  at  the  IMM  prior  to  introducing 
the  SSRs  into  the  computer  processing  cycle.  Transmission  and 
processing  times  will  be  considered  in  the  network  analysis  later 
on  in  this  Chapter. 

The  SSR  Procedures  prescribe  the  use  of  YX  advice  to 
provide  a  new  support  date.  The  procedures  also  permit  the  use  of 
the  YA  advice  to  provide  a  new  support  date,  but  only  two  of  the  YA 
advice  transactions  received  during  the  entire  eight  months  data 
collection  period  had  valid  new  support  dates.  Although  the  YA 
is  used  principally  as  an  NSN  notification  card,  NSNs  are  being 
provided  on  the  other  types  of  advice  cards.  The  SSR  Procedures 
are  subject  to  interpretation  on  the  use  of  other  types  of  advice 
transactions  to  provide  an  NSN.  Figure  1-47  provides  the  per¬ 
centage  of  times  that  NSNs  were  provided  in  accept  advice. 


The  100%  for  YA  advice  is  expected  since  this  is  an 
NSN  notification  card.  The  1. v  percentage  of  NSNs  for  YB  items 
is  attributable  to  GSA,  since  GSA  has  a  policy  of  decentralizing 
items  even  though  actual  demand  data  has  not  been  experienced. 
Since  the  YE  is  a  final  accept  for  an  NSN  SSR  and  an  initial 
accept  for  a  part  number  SSR  the  5.7%  is  not  surprising.  Since 
the  YX  is  usually  assigned  to  part  numbered  items  prior  to  re¬ 
ceiving  an  NSN  that  has  been  requested  from  DLSC,  it  is  unusual 
to  see  YX  provided  on  an  item  with  an  NSN  assigned.  Some  of  the 
NSNs  in  the  Y-based  YD  transactions  are  the  same  as  contained  in 
the  request  transaction. 

c •  Offer/Reply  Analysis 


Figure  1-48  provides  statistics  for  offers  and  replies 
to  offers  for  C1MM  items.  Only  six  offers  and  two  reply  offers 
were  received  for  WIMM  items;  therefore,  the  offer/reply  analysis 
is  restricted  to  C1MM  items. 

The  double  line  between  offers  and  replies  to  offers 
signifies  that  offers  and  replies  to  offers  do  not  necessarily 
relate  to  one  another.  Because  of  the  cutoffs  for  the  data  col¬ 
lection  there  may  be  some  offers  at  the  end  of  population  periods 
for  which  there  is  no  reply.  In  addition  some  of  the  replies  to 
offers  were  sent  by  mail  and  were  not  sent  to  the  study  team  for 
inclusion  in  the  data  collection  and  analysis. 

The  Component  and  system  average  percentages  are 
relatively  stable  from  period  to  period  during  the  data  collec¬ 
tion,  while  the  actual  volumes  of  transactions  were  different  for 
each  of  the  periods.  Although  the  Component  and  system  average 
percentages  were  compatible,  there  were  some  fluctuations  for  a 
few  activities  from  period  to  period.  The  percentages  for  offers 
shown  here  are  the  percent  of  all  CIMM  supply  support  request 
transactions  which  resulted  in  an  offer. 

The  replies  to  offers  also  were  stable  from  period  to 
period  on  a  percentage  basis.  The  percentage  of  acceptance  of 
offers  varied  by  less  than  one  percent  from  period  to  period. 
Rejects  of  offers  also  varied  by  less  than  one  percent  from 
period  to  period.  The  average  acceptance  rate  was  about  97%. 

Only  one  offer  was  made  for  NSN  and  two  for  PSCN  items  during  the 
entire  transition  period.  Only  two  replies  to  offers  for  NSN/ 

PSCN  items  were  received  during  the  steady  state  period. 
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ATC  OFFER/REPLY  ANALYSIS  BY  SUBMITTER 
(No.  and  X  of  Row  Total  for  OICs  CXA/CXB/CXC) 


Offers 

i  Replies  to  Offers  I 

Offer 

i  Accept 

Reject 

Total  | 

S1CC 

No. 

* 

No. 

X 

No. 

X 

No. 

X 

ARRCOM 

40 

5.5 

22 

91.7 

2 

8.3 

24 

100.0 

CERCOM 

132 

5.9 

0 

0.0 

o 

0.0 

0 

0.0 

MIRCOM 

21 

5  1 

3 

100.0 

0.0 

3 

100.0 

TARCOM 

41 

1.8 

1 

33.3 

66.7 

3 

100.0 

TSARCOM 

32 

0.9 

2 

66.7 

33.3 

3 

mm 

266 

2.8 

28 

84.8 

5 

15.2 

33 

100.0 

ASO 

Kl 

5.5 

378 

mm 

4 

1.0 

382 

100.0 

SPCC 

3.4 

0 

■sa 

3 

100.0 

3 

100.0 

mm 

BBS 

mm 

378 

98.2 

■1 

1.8 

385 

100.0 

OCALC 

0 

0.0 

0 

0.0 

0 

o 

0.0 

OOALC 

0 

0.0 

0 

0.0 

0 

0.0 

0 

0.0 

SAALC 

326 

2.2 

72 

69.2 

32 

30.8 

104 

100.0 

SHALC 

2,849 

9.6 

1,999 

99.1 

19 

0.9 

2,018 

100.0 

WRALC 

260 

2.5 

121 

99.2 

1 

0.8 

122 

100.0 

AF 

m 

6.2 

BIB 

97.7 

52 

2.3 

100.0 

HCLSBL 

195 

2.8 

104 

HI 

10 

8.8 

114 

100.0 

MC 

195 

2.8 

104 

91.2 

10 

8.8 

114 

100.0 

EG1CP 

0 

0.0 

0 

0.0 

0 

0.0 

0 

0.0 

SICP 

0 

0 

0.0 

mm 

0.0 

0 

0.0 

A1CP 

■EBI 

0 

0.0 

1 

0.0 

0 

0.0 

CG 

0 

0.0 

0 

Iff! 

m 

0.0 

0 

■H 

Other 

634 

6.2 

51 

100.0 

■9 

mm 

mm 

100.0 

Total 

■i 

m 

97.4 

74 

2.6 

mm 

100.0 

Source:  DODSSR  Data  Collection;  Transition  Population 


Figure  1-48 
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The  sum  of  offer  accepts  and  reje 
to  the  total  number  of  offers  during  any  one 
this  is  partially  explainable  due  to  the  cuto 
explanations.  When  an  1MM  makes  an  offer  to  a 
60  days  from  the  date  of  the  offer,  to  provid 
reply  has  not  been  received  within  60  days  of 
offer,  the  1MM  can  send  an  advice  card  reject 
item  originally  requested.  The  SICC  must  the 
if  support  is  desired.  Also  some  of  the  SICC 
paring  replies  and  mailing  them  out.  The  man 
been  processed  manually  to  update  the  files  o 
the  computer.  This  manual  processing  can  Inc 
time  and  result  in  support  rejects.  These  re 
been  excluded  from  suspense  file  maintenance 
DODSSR  Data  Collection. 
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Figure  1-49  was  generated  by  analyzing  the  counts 
of  ATCs  applicable  to  offers,  offer  accepts,  offer  rejects  and 
reject  of  support  when  a  reply  was  not  received. 

OFFER/REPLY/SUPPORT  REJECT  STATISTICS 
(Number  of  Advice  Transactions  by  Period) 


Population 

Offers 

Offer 

Accepts 

Offer 

Rejects 

Support 

Rejects 

Sum  Cols 

3  to  5 

Main 

12,448 

4,293 

127 

4,503 

8,923 

Transition 

7,058 

2,798 

79 

3,787 

6,664 

Steady  State 

5,006 

1,082 

36 

523 

1,641 

Source:  DOOSSR  Data  Collection 


Figure  1-49 


The  transition  period  is  the  only  period  for  which 
the  sum  of  the  offer  accepts  and  rejects,  and  support  rejects 
comes  close  to  the  number  of  offers.  This  is  probably  due  to  the 
data  collection  cutoff  periods,  the  selection  of  periods  using 
the  DOR  as  the  criteria  for  apportioning  the  data  into  periods, 
and  the  crossover  in  the  mail  or  AUTODIN  of  rejects  and  support 
rejects  of  offer  accepts  in  addition  to  the  reasons  cited  above . 
If  the  sum  of  the  offer  accepts,  offer  rejects  and  support  re¬ 
jects  of  offers  from  the  transition  period  is  used  as  a  base; 
then  of  all  the  offers  in  a  given  period,  on  an  average,  42%  are 
accepted  by  the  SICC,  1.2%  are  rejected  by  the  SICC,  and  56.8% 
are  effectively  withdrawn  by  the  IMM  because  the  SICC  failed  to 
reply  in  time. 
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When  the  SICC  does  reply  to  an  offer,  the  offer  is 
accepted  almost  97%  of  the  time.  Based  upon  this  overwhelming 
acceptance  of  offers,  it  is  not  understood  why  there  is  such  a 
high  offer  reply  delinquency  rate  on  the  part  of  the  SICCs. 

The  individual  ATCs  for  offers/replies/offer  with¬ 
drawals  were  analyzed  in  an  attempt  to  determine  the  reason  for 
the  high  delinquency  rate.  The  applicable  ATCs  have  been  ex¬ 
tracted  from  the  SSR  Procedures  and  are  listed  below: 

Offer  -  YL :  Offer  of  an  NSN  item  as  an  alternate  or 
substitute . 

-  YQ :  Offer  of  a  part  numbered  item. 

Offer  Accept  -  YM:  Accept  NSN  offer. 

-  YV :  Accept  part  number  offer. 

Offer  Reject  -  YN :  NSN/Part  Number  offer  rejected.  Original 

part  number  requested  is  required. 

-  YP :  NSN  offer  is  rejected.  Original  NSN 

requested  on  NSN  in  cc  8-20  is  required. 

No  Offer  Reply  -  08:  The  submitting  activity  has  failed  to 

reply  to  IMM  offer  within  60  days.  Sup¬ 
port  is  rejected.  A  new  SSR  must  be 
submitted  if  the  SICC  desires  to  accept 
the  original  offer. 

Figure  1-50  shows  a  breakdown  of  the  types  of  offers, 
offer  accepts  and  offer  rejects,  and  indicates  the  percentage  of 
each  ATC  to  the  column  heading.  Most  of  the  offers  (86.8%)  were 
NSNs,  so  naturally  most  of  the  offer  acceptances  were  NSN  accepts. 
But,  it  is  interesting  to  note  that  not  one  YP  (NSN  Offer  Rejected) 
occurred  during  the  Transition  Period,  or  during  the  entire  eight- 
month  data  collection  period.  Note  that  there  are  codes  for 
accepting  and  rejecting  NSNs  and  part  numbers,  but  no  code  for 
offering,  accepting  and  rejecting  PSCNs . 

OFFER/REPLY  ATC  ANALYSIS 
(%  of  Category) 


Offer 

Offer 

Offer 

Accept 

Reject 

YL  86.8% 

YM  84.6% 

YN  100.0% 

YQ  13.2% 

YV  15.4% 

YP  0.0% 

Source:  DODSSR  Data  Collection;  Transition  Population 

Figure  1-50 
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Since  most  of  the  offers 
1 8  a  high  acceptance  rate,  it  is  not 
i 8  such  a  high  delinquency  rate  of  re 
indicates  a  lack  of  offers  on  NSN  req 
didate  for  deletion.  Support  rejects 
offer  were  reviewed  on  an  activity  ba 
processing  and  loss  of  data  for  offer 
were  not  directly  relatable  to  the  of 
replies  and  support  rejects  could  not 
basis  to  determine  relative  activity 
transactions  appear  to  be  more  stable 
Figure  1-51  provides  the  relationship 
on  an  activity  and  Component  basis. 


are  for  NSN  items  and  there 
totally  understood  why  there 
plies.  The  zero  rate  for  YP 
uests  and  this  code  is  a  can- 
for  lack  of  a  reply  to  an 
sis.  Because  of  the  manual 
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fers  and  replies  and  the 
be  summed  up  on  an  activity 
delinquency.  Since  offer 
than  reply  transactions 
of  offers  to  support  rejects 


OFFER/NO  OFFER  REPLY  RELATIONSHIP  BY  SUBMITTER 


SICC 


ARRCOM 

CERCOM 

MIRCOM 

TARCOM 

TSARCOM 


ASO 

SPCC 


OCALC 

OOALC 


Offers 
No . 


1,204 

2,474 


SAALC 

SMALC 

WRALC 

327 

2,849 

286 

219 

1,314 

77 

67.0 

46.1 

26.9 

AF 

3,462 

wm 

46.5% 

MCLSBL 

197 

87 

44.2% 

MC 

197 

87 

44.2% 

Total 

6,403 

■RH 

49.9% 

Source;  DODSSR  Data  Collection;  Transition  Period 
Figure  1-51 
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The  number  of  offers  does  not  exactly  match  those  In 
Figure  1-48  because  all  offers  and  replies  In  Figure  1-48  had 
to  match  up  with  a  request  transaction  while  those  In  Figure  1-51 
show  the  raw  counts  of  offers  and  support  rejects  (ATC  08).  The 
support  reject  rate  Indicates  that  SPCC  must  have  been  submitting 
offer  replies  manually  and  that  a  number  of  them  were  missing 
from  the  data  collection  because  of  their  15. 6%  support  reject 
rate  shown  here.  By  contrast  SMALC  in  the  Air  Force  while  reply¬ 
ing  to  70.8%  of  their  offers,  had  a  46.1%  support  reject  rate 
indicating  that  there  must  have  been  a  delay  somewhere  in  the 
process  causing  the  replies  to  be  received  more  than  60  days 
after  the  date  of  the  offer.  The  same  is  true  for  ASO  in  the 
Navy  with  a  92.4%  support  reject  rate.  Except  for  the  15.6% 
reject  rate  for  SPCC,  the  picture  looks  rather  bleak  from  a  sub¬ 
mitter  viewpoint.  There  appears  to  be  a  combination  of  activity 
and  system  problems  on  the  submitter's  side. 

Figure  1-52  shows  the  support  reject  to  offer  ratio 
from  the  receiver's  side. 

OFFER/NO  OFFER  REPLY  RELATIONSHIP  BY  RECEIVER 


IMM 

Offers 

HESQSSU 

Support  Rejects 
Divided  by  Offers 

DCSC 

148 

81 

54.7% 

DESC 

5,688 

3,138 

55.2 

DGSC 

390 

228 

58.5 

DISC 

598 

340 

56.9 

GSA 

229 

0 

0.0 

Total 

7,053 

3,787 

53.7% 

Source:  D00SSR  Data  Collection,  Transition  Period 


Figure  1-52 

The  support  reject  rate  on  no  replies  to  offers  ap¬ 
pears  to  be  fairly  consistent  among  the  DLA  Supply  Centers.  How¬ 
ever,  it  is  surprising  to  note  that  GSA  did  not  reject  any  SSR 
because  a  reply  was  not  received  to  an  offer  it  had  made  to  an 
SICC.  This  was  true  for  the  entire  data  collection  period  even 
though  GSA  made  229  NSN  offers  during  the  Transition  Period  and 
311  NSN  offers  during  the  entire  data  collection.  GSA  did  not 
offer  any  part  numbered  items. 

Figure  1-53  breaks  down  the  Replies  to  Offers  by 
Receiver  (1MM)  for  CIMM  items.  Only  DLA  and  GSA  are  shown  since 
TaRCOM  had  no  replies  during  the  period. 
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REPLIES  TO  OFFERS  BY  RECEIVER 
(Percent) 
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Source:  DODSSR  Data  Collection;  Transislton  Popula¬ 

tion 


Figure  1-53 

The  acceptance  rate  for  IMM  offers  of  CIMM  items  is 
very  good.  Particularly  noteworthy  are  the  rates  of  DESC  and 
GSA.  DESC  offers  included  16. L%  part  numbers  while  GSA  did  not 
forward  any  part  numbered  offers.  The  rates  for  the  other  cen¬ 
ters  were  DCSC  -  0.7%,  DGSC  -  2.6%,  and  DISC  -  0.7%.  The  high 
rate  of  part  numbered  offers  by  DESC  is  attributed  to  the  use  of 
technical  personnel  in  performing  technical  screening  and  stan¬ 
dardization  before  NSN  assignment  rather  than  after.  The  accep¬ 
tance  rate  for  DISC  is  significantly  lower  than  for  the  other 
IMMs.  This  can  only  be  attributed  to  activity  differences. 

d .  Pending  Analysis 

The  SSR  Procedures  provide  two  ATCs  to  indicate  sta¬ 
tus  from  an  IMM  to  a  SICC  on  the  processing  of  an  SSR: 

ATC  64  -  This  code  is  used  only  for  WIMM  items  to  advise  of 
a  delay  pending  the  receipt  of  adequate  technical 
data . 

ATC  67  -  Used  by  both  CIMM/WIMM  to  advise  that  the  final 

support  determination  is  pending  and  will  be  pro¬ 
vided  within  15  days. 

Code  64  did  not  occur  in  the  entire  eight  months  data 
collection  period.  Since  a  WIMM  generally  is  required  to  have 
technical  data  for  WIMM  items,  this  code  appears  to  be  a  candi¬ 
date  for  elimination.  Codes  YS  and/or  44  appear  to  overlap  or 
duplicate  Code  64.  Code  67  appears  only  563  times  during  the 
entire  data  collection  period.  This  is  0.2%  of  the  time.  The 


only  apparent  usage  for  this  code  Is  to  advise  that  processing  of 
an  SSR  Is  Incomplete,  but  recognizes  that  the  SSR  has  been  received 
and  Is  In  processing.  Despite  its  low  usage  there  should  be  at 
least  one  code  to  advise  that  an  SSR  has  been  received.  Is  in 
processing  and  that  a  final  determination  has  not  yet  been  made. 

e.  Reject  Analysis.  The  study  team  concluded  as  a  result 
of  the  overall  advice  analysis  in  Paragraph  C.4.a.  above  that  the 
rates  for  the  Reject  Category  of  advice  were  too  high.  The  reject 
advice  was,  therefore,  broken  down  into  subcategories  and  analyzed 
by  subcategory  as  well  as  individual  ATC  within  subcategory.  Fig¬ 
ure  1-33  grouped  all  the  ATCs  into  categories  and  subcategories. 

The  reject  category  just  has  too  many  ATCs  to  list  each  of  them 
and  to  provide  a  definition  and  usage  for  each  one  of  them.  That 
is  the  reason  that  the  reject  category  was  broken  down  into  sub¬ 
categories.  Particular  ATCs  will  be  referred  to  and  defined  if 
they  show  up  as  significant  during  the  review  of  the  reject  sub¬ 
categories. 

(1)  Reject  Category  Analysis.  Reports  in  this  sec¬ 
tion  will  group  rejects  by  reject  category  and  compare  the  cate¬ 
gories  to  each  other.  Subsequent  sections  will  provide  a  detailed 
analysis  of  the  individual  reject  categories.  Since  some  of  the 
reports  in  this  section  will  be  displayed  by  Component  and  activ¬ 
ity,  extracts  of  the  relative  volumes  of  SSRs  submitted  by  each 
activity  and  Component  are  shown  in  Figures  1-54  and  1-55  to  per¬ 
mit  an  analysis  of  reject  rates  in  respect  to  volume  of  business 
by  activity  or  Component. 

(a)  C1MM 

The  41.93!  reject  rate  for  all  CIMM  SSRs 
shown  previously  in  Figure  1-40,  was  considered  to  be  much  too 
high  by  the  study  team.  In  order  to  ascertain  the  reason  for  the 
high  reject  rate  a  series  of  reports  were  generated  to  breakdown 
rejects  into  meaningful  subcategories  such  as  is  shown  in  Figures 
1-56  and  1-57. 

Invalid  data  and  other  errors  account  for 
over  503!  of  all  the  rejects.  Invalid  data  rejects  are  validation 
errors.  The  Army  and  Marine  Corps  rates  of  over  503!  of  their 
rejects  due  to  invalid  data  are  well  above  the  system  average. 
Together  they  accounted  for  almost  48%  of  the  total  validation 
rejects  although  they  account  for  only  153!  of  the  total  request 
volume.  This  is  attributed  to  the  use  of  manual  systems  for  the 
generation  of  SSRs  during  the  time  of  the  study.  There  also  was 
no  automated  system  for  the  validation  of  outgoing  SSRs  in  use  by 
the  Army  and  the  Marine  Corps  at  the  time  of  the  data  collection. 
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GROSS  LISSR  VOLUMES  FROM  SICC  TO  IMM 
(Percent  of  Column  Total  by  Submitter) 
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Figure  1-54 
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GROSS  LISSR  VOLUMES  FROM  SICC  TO  IMM 
(Percent  of  Column  Total  by  Receiver) 
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ATC  ADVICE  ANALYSIS  BY  SUBMITTER 


(Summary  of  Rejects  for  DICs  CXA/B/C) 
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The  Navy  recorded  the  highest  number  of 
Other  rejects.  Thirty-five  percent  of  their  rejects  were  attrib¬ 
utable  to  this  category,  and  approximates  their  volume  of  request 
transactions.  The  Navy  count  was  primarily  due  to  SPCC.  The  Navy 
also  experienced  a  28.52  error  rate  due  to  DLSC  screening.  The 
FSC/Manager  and  NSN/PSCN  columns  constitute  rejects  because  the 
I MM  picked  up  Information  during  DLSC  screening  that  should  have 
been  obtained  and  included  in  the  SSR  by  the  SICC.  The  Navy  re¬ 
corded  over  572  of  the  NSN/PSCN  rejects  while  accounting  for  342 
of  the  total  requests.  The  Air  Force  is  higher  than  the  system 
average  for  catalog/technical  data  and  for  match/duplication 
errors.  The  Air  Force  accounted  for  over  652  of  the  catalog/ tech¬ 
nical  data  rejects  and  over  882  of  the  match/duplication  errors. 

In  order  to  determine  the  influence  of  NSN 
versus  part  number  requests  CXA  rejects  are  shown  in  Figure  1-58 
and  1-59. 

The  46.92  Invalid  Data  reject  rate  for  NSN 
requests  is  significantly  higher  than  the  31.52  for  all  requests 
indicating  a  much  higher  reject  rate  due  to  validation  for  NSN 
items.  This  is  somewhat  unusual  since  there  are  fewer  cards  and 
data  elements  required  to  request  support  for  an  NSN  than  for  a 
part  numbered  item.  The  basic  elements  of  data  needed  to  request 
support  for  an  NSN  should  be  the  document  identifier  code,  the 
NSN,  the  activity  codes  (from  and  to),  and  the  quantities  re¬ 
quested*  in  addition  to  the  control  data  elements. 

The  702  invalid  data  reject  rate  for  the 
Army  is  astronomical.  The  Army  rejects  can  be  attributed  to 
problems  associated  with  DLSC  screening,  and  data  entry  and  vali¬ 
dation.  The  Navy  accounted  for  over  502  of  all  the  rejects  for 
NSN  items.  This  is  principally  due  to  rejects  received  by  SPCC. 
The  52.72  reject  rate  for  the  Navy  compares  with  the  44.62  volume 
of  its  NSN  requests.  The  validation  errors  for  all  Components 
for  NSN  requests  are  too  high  across  the  board.  There  can  and 
should  be  a  lot  of  improvement  in  the  preparation,  DLSC  screening, 
data  validation,  transmission  and  processing  of  NSN  SSRs. 

Figures  1-60  and  1-61  provide  statistics 
for  part  numbered  rejects. 

The  invalid  data  rejects  at  16.42  are  much 
more  favorable  than  for  NSN  requests.  Of  this  amount  the  Army 
and  Air  Force  were  the  biggest  contributors.  The  rate  of  valida¬ 
tion  rejects  is  still  much  too  high.  The  much  higher  rate  of 
26.72  for  part  numbers  over  0.12  for  NSNs  for  catalog/technical 
data  1 s  expected.  The  errors  for  part  numbered  items  appear  to 
be  more  evenly  distributed  among  activities  and  Components  than 
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Figure  1-59 
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ATC  ADVICE  ANALYSIS  BY  SUBMITTER  FOR  CXB  TRANSACTIONS 
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Figure  1-61 
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for  NSNs.  TSARCOM  and  Marine  Corps  are  high  for  FSC/Manager 
errors.  Although  the  Air  Force  9.2%  of  this  category  equals  the 
average  total  in  Figure  1-60,  Figure  1-61  indicates  that  the  Air 
Force  accounts  for  almost  58%  of  the  FSC/Manager  errors,  and 
65.2%  of  the  catalog/technical  data  rejects.  The  Air  Force  also 
accounted  for  95.7%  of  the  match/duplication  errors  for  part  num¬ 
bered  items. 


The  volumes  of  PSCN  items  were  too  small  to 
warrant  a  table  to  summarize  the  rejects.  NSNs/PSCNs  accounted 
for  29.4%,  Invalid  Data  for  38.3%,  and  Match/Duplicate  for  17.6%. 

Because  of  the  large  amount  of  data  and 
processing  time  required  to  analyze  the  data,  receiver  statistics 
were  run  only  on  the  total  population  of  data.  The  total  figures 
will  be  slightly  different  due  to  the  time  period  although  pro¬ 
portions  are  comparable.  Figures  1-62  and  1-63  provide  data  for 
all  the  CIMM  rejects  by  IMM. 

DCSC  and  GSA  are  significantly  higher  on 
FSC/Manager  errors  than  the  system  average  for  that  category, 
while  DESC  is  significantly  below  the  average.  The  rate  of  re¬ 
jects  in  this  category  exceed  the  proportion  of  requests  for  DCSC 
and  GSA.  DESC  is  above  the  category  average  for  NSN/PSCN.  Since 
these  rejects  are  due  to  DLSC  screening  deficiencies  upon  the 
part  of  the  submitters,  it  is  not  known  why  these  variances  exist. 
GSA  is  significantly  high  for  catalog/technical  data  rejects  at  a 
rate  of  over  1.5  times  its  request  volume.  This  confirms  the  GSA 
comment  during  field  research  concerning  the  quantity  and  quality 
of  technical  data  that  it  was  receiving.  GSA  is  extremely  low  as 
compared  to  the  system  average  for  validation  rejects.  This  is 
attributed  to  manual  processing  and  editing  by  GSA  and  the  less 
stringent  criteria  for  acceptance  of  SSRs  when  non-key  data  ele¬ 
ments  are  missing  or  invalid.  This  rate  is  much  more  in  line 
with  what  a  properly  functioning  system  should  expect  for  valida¬ 
tion  rejects.  The  high  incidence  of  match/duplicate  rejects  for 
GSA  is  not  understood.  The  other  category  shows  a  high  incidence 
for  DESC.  This  is  attributed  to  the  intensive  technical  screening 
effort  by  DESC  and  the  use  of  ATC  36  requiring  information  to  be 
returned  to  the  submitter  on  an  exception  basis. 

An  analysis  of  the  differences  in  NSN  and 
part  number  rejects  for  receivers  tends  to  confirm  the  analyses 
presented  above  for  submitters.  There  did  not  appear  to  be  any 
significant  variances  between  MSN  and  part  numbered  items  among 
D LA  activities.  The  0.3%  validation  reject  rate  for  GSA  is  for 
NSN  items  extremely  good  and  tends  to  confirm  the  observation  of 
the  DODSSR  Study  Team  that  only  minimal  data  is  required  to  pro¬ 
cess  and  accept  supply  support  for  an  NSN  item. 
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The  FSC/Manager  (22. OX),  Catalog/TD  (7.9fc) 
and  MaCch/Duplicate  (50. 8X)  for  NSN  items  all  were  above  the  sys¬ 
tem  averages  and  GSA  request  percentages.  There  should  not  be  a 
problem  In  determining  the  FSC/Manager  for  an  NSN  item  and  Cata¬ 
log/Technical  Data  is  not  required  for  an  active  NSN  item.  It  is 
not  understood  why  there  should  be  such  a  high  match/duplicate 
rate  for  NSN  items  for  GSA. 

(b)  WIMM 

Figure  1-64  displays  the  statistics  for 
rejects  by  submitter  for  WIMM  items.  If  the  item  had  been  pro¬ 
perly  screened  with  DLSC  over  56%  of  the  rejects  would  have  been 
unnecessary.  ASO  in  the  Navy  has  the  greatest  volume  of  rejects 
in  this  area.  This  is  particularly  true  since  the  vast  majority 
of  WIMM  SSRs  are  for  NSN  items.  The  Marine  Corps  experienced 
54.1%  of  their  rejects  due  to  Invalid  data  which  indicates  im¬ 
proper  entry  of  data  when  preparing  SSRs. 

Figure  1-65  presents  data  for  WIMM  IMMs. 
From  a  receiver  basis  the  Navy  seems  to  be  the  recipient  of  the 
greatest  volume  of  FSC/Manager  errors,  while  the  Air  Force  re¬ 
ceives  the  largest  number  of  NSN/PSCN  errors.  As  an  I MM,  the 
Air  Force  rejects  the  most  WIMM  SSRs  due  to  invalid  data. 

(2)  Individual  ATC  Analysis 

The  previous  analytical  reports  permitted  an 
analysis  of  SSR  rejects  by  subdividing  the  rejects  into  major 
gubcategories.  This  allowed  identification  of  the  major  areas 
where  rejects  were  occurring  by  type  of  error  and  by  submitting 
and  receiving  activity  or  Component  where  the  errors  were  oc¬ 
curring  most  frequently.  In  order  to  more  fully  understand  the 
reason  for  the  occurrence  of  the  major  reject  categories,  it  was 
necessary  to  determine  the  occurrence  of  lndiviudal  ATCs  within 
these  categories.  This  was  needed  due  to  the  large  number  of 
individual  ATCs  constituting  some  of  the  reject  categories. 

An  analysis  was  first  made  of  the  frequency  of 
occurrence  of  all  ATCs  regardless  of  category  for  each  of  the 
data  base  populations.  This  was  done  in  order  to  determine  which 
population  or  populations  should  be  selected  to  be  used  for  com¬ 
parison  with  the  results  of  the  AUTODIN  and  TELEFAX  tests.  All 
ATCs  for  each  population  with  a  frequency  of  occurrence  of  1%  or 
greater  or  those  in  the  top  20  rank  in  terms  of  greatest  fre¬ 
quency  of  occurrence  were  selected  and  placed  in  a  Population/ 

ATC  Rank  Matrix.  The  ATCs  were  placed  in  ascending  order  and 
compared.  The  main,  transition  and  steady  state  populations  were 
similar  throughout  the  ranking.  The  first  eight  ranks  were  al¬ 
most  identical  and  the  ranks  were  very  similar  through  the  top 
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ATC  ADVICE  ANALYSIS  BY  SUBMITTER 


(Summary  of  X  of  Row  Total  for  DICa  WXA/B) 


ARRCOM 

0.0 

0.0 

0.0 

0.0 

0.0 

CERCOM 

12.5 

0.0 

0.0 

25.0 

0.0 

MIRCOM 

0.0 

0.0 

0.0 

100.0 

0.0 

TARCOM 

0.0 

100.0 

0.0 

0.0 

0.0 

TSARCOM 

31.3 

12.5 

0.0 

0.0 

0.0 

Army 

22.2 

11.1 

0.0 

11.1 

0.0 

ASO 

72.5 

11.6 

0.0 

2.9 

0.0 

SPCC 

0.0 

0.0 

0.0 

0.0 

0.0 

Navy 

72.5 

11.6 

0.0 

2.9 

0.0 

OCALC 

0.0 

0.0 

0.0 

0.0 

0.0 

OOALC 

100.0 

0.0 

0.0 

0.0 

0.0 

SAALC 

100.0 

0.0 

0.0 

0.0 

0.0 

SMALC 

64.7 

17.6 

0.0 

5.9 

5.9 

WRALC 

26.1 

8.7 

0.0 

0.0 

30.4 

AF 

45.3 

11.9 

0.0 

2.4 

19.0 

MCLSBL 

18.9 

5.4 

8.1 

54.1 

0.0 

MC 

18.9 

5.4 

8.1 

54.1 

0.0 

EGICP 

0.0 

0.0 

0.0 

0.0 

0.0 

SICP 

0.0 

0.0 

0.0 

0.0 

0.0 

AICP 

100.0 

0.0 

0.0 

0.0 

0.0 

CG 

100.0 

0.0 

0.0 

0.0 

0.0 

Other 

0.0 

25.0 

0.0 

75.0 

0.0 

Total 

46.1 

10.6 

1.7 

16.1 

4.4 

100.0 

62.5 

0.0 

0.0 

56.2 


Source:  Data  Collection;  Steady  State  Population 

Figure  1-64 
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ATC  ADVICE  ANALYSIS  BY  I MM 
(Summary  of  X  of  Row  Total  for  DICs  WXA/B) 


IS  ranks*  There  was  only  one  code  In  each  of  the  populations 
that  was  not  Included  In  all  three  populations.  However,  the 
main  and  transition  populations  contained  more  Invalid  codes  and 
some  that  were  attributable  to  conversion  from  the  old  to  the  new 
system.  In  addition,  the  steady  state  population  was  considered 
more  representative  of  the  actual  system  as  operating  and  more 
compatible  and  comparable  with  the  test  populations.  The  steady 
state  population  was  thus  selected  as  the  base  population  for 
analysis  of  the  system  and  for  comparison  with  the  test  popula¬ 
tions  . 

Figure  1-66  shows  the  frequency  of  occurrence 

of  ATCs. 

ATC  FREQUENCY  OF  OCCURRENCE 
(Valid  ATCw ) 


Number 

ATCs 

Cumulative 

Number 

ATCs 

Percent 

Frequency 

Range 

Percent 

Frequency 

Percent 

Cumulative 

Frequency 

3 

3 

8.3Z 

to 

32. 9Z 

51. 6Z 

51. 6Z 

6 

9 

2.8 

to 

8.2 

24.5 

76.1 

11 

20 

0.8 

to 

2.7 

15.3 

91.4 

7 

27 

0.5 

to 

2.6 

4.3 

95.7 

19 

46 

0.1 

to 

2.5 

4.0 

99.7 

16 

62 

0.001 

to 

0.09 

0.3 

100.0 

8 

70 

o.oz 

to 

O.OZ 

O.OZ 

100. OZ 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-66 

Although  there  are  70  possible  ATCs  available 
for  assignment  in  the  SSR  Procedures,  there  is  a  wide  disparity 
in  their  usage.  Three  ATCs  accounted  for  over  50X  of  the  usage. 
Less  than  20  of  the  codes  are  used  IX  or  more  of  the  time,  and 
eight  codes  experienced  no  usage  at  all  during  the  base  period. 

Figure  1-67  dramatically  depicts  the  fact  that 
very  few  codes  account  for  the  majority  of  usage  and  that  a  large 
number  of  codes  have  little  or  no  usage.  Those  codes  with  an  ex¬ 
tremely  low  record  of  usage  should  be  considered  for  deletion  and 
or  consolidation  with  other  codes.  Codes  with  a  usage  of  less 
than  1Z  should  be  considered  candidates  for  review  and  those  with 
less  than  0.5Z  should  be  considered  prime  candidates  for  deletion 
based  upon  usage  alone.  This  confirms  the  complaints  of  using 
activities  that  there  were  too  many  codes  with  too  many  conflict¬ 
ing  and  overlapping  meanings  and  usages.  This  causes  the  user  to 
sometimes  incorrectly  apply  a  code  on  the  sending  side  or  to  mis¬ 
interpret  a  code  on  the  receiving  end. 
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CUMULATIVE  FREQUENCY  DISTRIBUTION  FOR  ATCs 


SOURCE:  DODSSR  DATA  COLLECTION;  STEADY  STATE  POPULATION 


Figure  1-67 
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A  separate  distribution  was  developed  for  reject 
codes  as  shown  in  Figure  1-68. 

REJECT  CODE  FREQUENCY  OF  OCCURRENCE 
(Valid  ATCs) 


Number 

ATCs 

Cumulative 

Number 

ATCs 

Percent 

Frequency 

Range 

Percent 

Frequency 

Percent 

Cumulative 

Frequency 

5 

5 

7.6% 

t  0 

13.2% 

50.1% 

50.1% 

6 

11 

2.4 

to 

13.1 

24.7 

74.8 

21 

1.1 

to 

13.0 

15.0 

89.8 

28 

0.6 

to 

1.0 

5.3 

95.1 

40 

0.1 

to 

0.5 

2.6 

97.7 

Kl 

50 

0.001 

to 

0.09 

2.3 

100.0 

1 _ 6 _ 

56 

0.0% 

to 

0.0% 

0.0% 

100.0% 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-68 

The  same  thing  holds  true  for  reject  codes  as 
for  the  total  population  of  ATCs.  A  very  few  codes  account  for 
the  majority  of  usage.  Five  codes  accounted  for  50%  of  the 
usage,  11  for  75%  of  the  action.  There  were  22  codes  with  0.5% 
or  less  usage  and  six  that  experienced  no  usage  at  all  during  the 
base  period. 


The  curve  for  reject  codes  as  shown  in  Figure 
1-69  is  very  similar  to  the  curve  for  all  ATCs.  The  reject  codes 
with  a  high  frequency  of  occurrence  should  be  reviewed  to  deter¬ 
mine  the  cause  for  the  high  rates  and  those  with  an  extremely  low 
usage  or  no  usage  at  all  should  be  reviewed  to  determine  if  the 
codes  not  being  used  can  be  consolidated  with  other  codes  or 
eliminated  entirely.  Reject  Code  51  showed  no  usage  in  the  data 
collection;  however,  this  code  is  manually  applied  and  mailed  to 
the  submitter  by  DLA .  Therefore,  although  there  is  known  usage 
it  cannot  be  statistically  measured  from  the  ATC  distribution  in 
the  data  collection. 

Reject  codes  with  the  highest  incidence  of 
occurrence  are  shown  in  Figure  1-70. 
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CUMULATIVE  FREQUENCY  DISTRIBUTION  FOR  REJECT  CODES 


SOURCE:  DODSSR  DATA  COLLECTION;  STEADY  STATE  POPULATION 


Figure  1-69 
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SYSTEM  REJECT  CODE  RANKING 


Rank 

■■KQ232S1 

ATC 

Definition 

% 

1 

Other 

36 

Exception  Data 

13.2 

2 

Other 

57 

Multiple  SSR  Same  Cycle 

12.6 

3 

Invalid  Data 

52 

Mandatory  PDSSR  Data 

8.6 

4 

Invalid  Data 

07 

Unit  Price  Error 

8.1 

5 

NSN/PSCN 

YR 

Nonstandard  Item 

7.6 

6 

Invalid  Data 

32 

Mandatory  LISSR  Data/ 
Missing  Cards 

6.4 

7 

NSN/PSCN 

34 

NSN  Match 

5.1 

8 

Catalog/Tech . 

Data 

YS 

Inadequate  Tech.  Data 

4.5 

9 

FSC/Manager 

YC 

FSC/Manager  Error 

3.7 

10 

FSC /Manager 

YK 

Manager  Error 

2.6 

11 

Catalog/Tech . 

Data 

14 

Part  Number  Format 

2.4 

12 

Catalog/Tech . 

Data 

19 

MIL  SPEC  Problem 

2.3 

13 

Invalid  Data 

23 

Quantity  Error 

2.1 

14 

Invalid  Data 

30 

AAC  J/Qty  Error 

2.0 

15 

Match/ Du plicate 

42 

Duplicate  NSN 

2.0 

16 

Catalog/Tech . 

Data 

44 

No  Tech.  Data 

1.8 

17 

Other 

08 

Delayed  Reply  to  Offer 

1.7 

18 

Catalog/Tech . 

Data 

21 

Part  Number/Tech.  Data 

1.5 

19 

Invalid  Data 

01 

Part  Number/FSCM  Missing 

1.4 

20 

NSN/PSCN 

YJ 

Cancelled/ Re placed 

1.1 

21 

NSN/PSCN 

45 

AAC  F,  T,  V,  W,  or  Y 

1.1 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-70 

This  table  shows  all  reject  codes  that  experi¬ 
enced  a  1%  or  greater  total  frequency*  The  codes  are  ranked 
showing  the  code  with  the  highest  frequency  of  occurrence  as 
number  one  and  the  lowest  frequency  with  the  highest  numerical 
rank.  These  21  reject  codes  account  for  almost  90Z  of  all  the 
rejects;  and  it  is  here  where  the  most  can  be  gained  by  deter¬ 
mining  the  reasons  for  occurrence  and  correcting  the  causes  for 
these  rejects* 

The  rejects  were  reviewed  by  Component  to  deter¬ 
mine  if  there  was  a  Component  influence  from  a  submitter  or  re¬ 
ceiver  standpoint,  that  was  weighting  the  code  in  the  rankings 
due  to  heavy  usage  by  a  particular  Component.  If  a  code  is  used 
uniformly  by  all  Components,  then  the  tendency  is  to  interpret 
the  reject  as  a  policy,  procedure  or  total  system  problem,  where¬ 
as  if  a  single  Component  is  using  a  particular  code  so  much  that 
it  influences  the  total  distribution,  the  tendency  is  to  view  it 
as  a  Component  problem. 


Figure  1-71  shows  a  comparison  of  the  top  ten 


system  rejects  and  the  corresponding  Component  rank  of  the  occur¬ 
rence  of  that  code  within  the  Component*  There  was  remarkable 
consistency  of  the  occurrence  of  codes  among  Components  for  the 
top  ten  system  rejects.  Those  in  the  second  ten  or  10  through  20 
of  Figure  1-70  were  quite  variable  among  the  Components  in  terms 
of  occurrence,  so  detailed  analysis  for  comparison  purposes  among 
the  Components  was  limited  to  the  top  ten  system  rejects  in  this 
table . 

REJECT  CODE  COMPARISON  BY  SUBMITTER 
(System  Top  Ten  Reject  Codes  vs.  Component  Ranking) 


ATC 

Rank 

Total 

Army 

Navy 

Air  Force 

Marine  Corps 

36 

1 

4 

4 

1 

3 

57 

2 

14 

1 

7 

5 

52 

3 

2 

5 

4 

4 

07 

4 

1 

3 

16 

* 

YR 

5 

8 

2 

18 

9 

32 

6 

5 

* 

2 

2 

34 

7 

6 

5 

7 

YS 

8 

1 

7 

3 

20 

YC 

9 

8 

6 

6 

YK 

10 

6 

9 

14 

10 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


*  Too  low  to  be  ranked. 

Figure  1-71 


Reject  Code  36  was  consistently  high  among  all 
the  Components,  but  ranked  number  one  in  the  Air  Force.  This 
code  occurred  19.4%  of  the  time  in  the  Air  Force.  The  three  ALCs 
with  the  highest  volume  of  SSR  traffic  recorded  this  as  their 
number  one  reject.  The  Air  Force  undoubtedly  is  a  significant 
factor  in  the  number  one  rating  for  this  code,  although  it  was 
high  in  the  ranking  for  all  the  Components.  This  code  is  used 
when  no  other  code  is  appropriate  or  when  exception  data  in  the 
form  of  "in  the  clear  remarks"  are  desired  to  be  provided  with 
the  reject.  The  high  rate  of  this  reject  is  exceptionally  bad 
because  the  remarks  must  currently  be  mailed  to  the  submitter  by 
the  1MM  causing  a  delay  in  processing.  A  large  number  of  the 
rejects  in  this  category  are  associated  with  part  numbers  that 
are  incorrect  or  are  improperly  formatted  IMC  conflicts,  offer 
conflicts  and  offshore  procured  items.  Consideration  should  be 
given  to  identifying  all  the  types  of  actions  encompassed  by  ATC 
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36  and  using  a  specific  ATC  to  identify  them  so  that  the  advice 
information  can  be  transmitted  to  the  SICC  by  AUTODIN.  An  Advice 
Card  with  a  reference  information  field  should  be  considered  for 
all  actions  remaining  under  ATC  36.  The  reference  information 
field  could  contain  "in  the  clear”  reference  information  needed 
to  provide  explanatory  advice  to  the  SICC  so  that  both  the  Advice 
Code  and  the  explanatory  information  could  be  sent  together  over 
AUTODIN.  This  would  preclude  the  necessity  of  matching  up  of  an 
ATC  36  advice  over  AUTODIN  and  the  explanatory  advice  currently 
provided  by  manual  DLA  Form  546.  The  DLA  Form  546,  although 
entitled  "Standard/Alternate  Item  Referral"  is  used  to  provide 
exception  information  for  ATC  36  rejects  as  well  as  for  offers. 

ATC  57  Indicates  that  there  have  been  multiple 
increases/decreases  to  a  quantity  field  within  the  same  cycle. 

This  code  is  applied  when  there  are  a  number  of  SSRs  for  the  same 
item  of  supply  from  the  same  activity  included  in  the  same  pro¬ 
cessing  cycle  by  DLA;  and  the  technical  subsystem  of  DLA  cannot 
accommodate  the  multiple  actions.  The  frequency  of  this  code  is 
heavily  dominated  by  the  Navy  and  by  SPCC  in  particular.  There 
was  a  28.2%  reject  rate  experienced  by  SPCC  for  this  condition. 

It  was  the  top  reject  rate  experienced  by  SPCC  during  the  time- 
frame.  This  is  attributed  to  the  tendency  of  SPCC  to  accumulate 
and  batch  SSRs  that  are  mailed  out  in  a  package.  The  Navy  system 
does  not  have  an  automated  convention  for  rolling  up  requirements 
for  the  same  item  and  sending  out  a  single  SSR  with  multiple  re¬ 
quirements.  SSRs  are  also  treated  on  an  individual  basis  by  the 
IMM  on  the  receiving  side.  Each  SSR  is  treated  individually  by 
the  IMM  for  the  purposes  of  making  range  and  depth  stockage  con¬ 
siderations  for  new  items  and  for  the  purposes  of  changing  the 
management  criteria  for  an  existing  managed  item.  Consideration 
should  be  given  to  accumulating  requirements  for  the  same  item  by 
the  SICC  or  the  IMM,  or  both.  In  the  event  that  accumulation  is 
not  desired  prior  to  making  a  support  decision,  consideration 
should  be  given  to  maintenance  of  a  demand  history  of  the  require¬ 
ments  quantities  in  SSRs  which  could  be  used  to  forecast  the 
accumulative  effect  of  requirements  for  SSR  items  for  the  purpose 
of  modifying  previous  stockage  and  management  decisions  made  by 
the  IMM  on  the  basis  of  individual  SSRs. 

ATC  52  rejects  were  experienced  fairly  uniformly 
by  all  the  Components.  This  reject  occurs  when  mandatory  data 
elements  are  missing  or  incorrect  on  a  PDSSR  record.  If  a  PDSSR 
is  rejected,  all  the  associated  line  item  requests  must  be  re¬ 
jected  along  with  the  program  data  card.  Because  of  the  inci¬ 
dence  of  occurrence  of  this  reject  code,  the  Study  Team  conducted 
a  review  of  the  data  elements  in  the  PDSSR  card  to  determine  the 
relative  usefullness  of  the  data  elements  and  the  appropriate 
validation  criteria  for  this  card  in  order  to  reduce  the  inci¬ 
dence  of  this  reject. 


ATC  07  is  heavily  influenced  by  the  16. 3%  reject 
rate  for  SPCC  in  the  Navy  even  though  this  was  the  top  ranked 
reject  in  the  Army.  The  Navy  accounted  for  about  38%  of  the 
total  reject  advice  while  the  Army  experienced  about  9%.  These 
volumes  are  directly  related  to  the  request  traffic  experienced 
by  the  Components.  Unit  price  is  currently  a  required  data  ele¬ 
ment  for  part  numbered,  inactive  NSN  or  PSCN  items.  It  is  not 
required  for  active  stock  numbered  items.  An  IMM  can  not  distin¬ 
guish  between  a  Condition  1  (active)  and  Condition  2  (inactive) 

NSN  through  the  use  of  control  data  in  an  SSR  such  as  the  docu¬ 
ment  identifier  code.  Certain  data  elements  are  required  by  the 
SSR  Procedures  for  inactive  NSNs  that  are  not  required  for  active 
NSNs  such  as  unit  price,  production  leadtime,  IMC ,  and  procure¬ 
ment  method  code.  The  IMM  must  differentiate  between  a  Condition 
1  or  2  item  by  detecting  the  presence  or  absence  of  a  combination 
of  these  data  elements.  During  the  data  collection  period  some 
activities  were  entering  some  but  not  all  of  the  required  data 
elements  for  a  Condition  2  item  in  a  Condition  1  request  result¬ 
ing  in  the  rejection  of  the  SSR  when  such  data  elements  as  the 
unit  price  were  excluded  but  others  such  as  procurement  method 
code  were  included.  The  distinction  and  necessity  for  Condition 
1  and  2  SSRs  for  NSN  items  need  to  be  clarified  along  with  the 
necessity  for  differing  data  element  requirements  for  active 
verus  inactive  NSN  items. 

The  Navy  recorded  the  highest  YR  reject  rate. 

The  18.6%  YR  reject  rate  experiehced  by  SPCC  is  the  principal 
reason  for  the  7.6%  system  rate  for  this  code.  Inadequate  DLSC 
screening  is  considered  a  major  cause  for  a  YR  reject. 

ATC  32  involves  a  reject  due  to  validation  be¬ 
cause  mandatory  data  elements  on  a  request  transaction  are  missing 
or  incorrect.  This  was  a  top  ten  item  for  all  Components,  except 
the  Navy.  The  percentage  for  this  reject  for  the  Navy  was  so  low 
that  it  did  not  qualify  for  ranking.  This  reject  rate  is  domi¬ 
nated  principally  by  the  Air  Force  with  SAALC  experiencing  an 
18.1%  rate,  SMALC  11.0%,  and  WRALC  8.1%. 

ATC  34  experienced  a  consistent  ranking  among 
all  the  Components,  as  did  Code  YC.  The  Air  Force  seemed  to  be 
the  dominant  influence  for  inadequate  technical  data,  Code  YS. 

Code  YR  was  also  fairly  uniform  among  the  Components;  however,  it 
was  not  a  top  ten  item  for  the  Air  Force. 

Figures  1-70  and  1-71  summarized  the  top  ten 
reject  codes  for  the  total  SSR  system  and  highlighted  those  re¬ 
jects  that  were  heavily  influenced  by  a  particular  Component  or 
activity.  Activity  or  Component  Influence  upon  the  system  is 
predicated  upon  both  a  high  reject  rate  for  particular  code  and 
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the  volume  of  SSR  requests  and  associated  advice  experienced  by 
the  activity  or  Component.  Figure  1-72  shows  reject  codes  that 
were  top  ten  rated  codes  for  a  particular  Component  but  were  not 
top  ranked  In  the  system  as  a  whole. 

REJECT  CODE  COMPARISON  BY  SUBHITTER 
(Component  Top  Ten  Reject  Codes  vs.  System  Ranking) 


Component 

ATC 

Component 

Rank 

Component 

Percent 

System 

Rank 

System 

Percent 

Army 

39 

3 

* 

* 

14 

9 

111^891^^1 

11 

2.42 

Navy 

45 

10 

1.62 

21 

1.12 

Air  Force 

■MB 

8 

m 

16 

1.82 

■ 

9 

11 

2.4 

10 

12 

2.3 

Marine 

30 

1 

30.02 

14 

2.02 

Corps 

YU 

8 

3.4 

* 

* 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


*  Too  low  to  be  ranked. 


Figure  1-72 

The  Army  accounted  for  about  92  of  the  total 
system  reject  advice;  therefore,  a  particular  reject  code  would 
have  to  have  a  very  high  experience  rate  throughout  the  Army  to 
influence  the  system  total.  Reject  Codes  39  and  14  were  top  ten 
rejects  in  the  Army  but  did  not  make  the  list  for  the  system. 

Code  39  even  though  ranking  number  three  in  Army,  was  unranked 
for  the  total  system.  ATC  39  is  a  validation  error  pertaining  to 
the  Reference  Number  Justification  Code.  Code  14  ranked  11  in 
the  system  was  number  nine  rank  in  the  Army.  The  rate  for  ATC  39 
in  the  Army  is  attributable  to  TSARCOM  with  a  31.52  reject  rate 
for  this  code  and  experiencing  about  one  third  of  the  Army's 
reject  advice.  The  Component  rate  for  Code  14  was  stable  around 
the  Army  average  for  that  code. 

The  Air  Force  had  three  codes  in  their  top  ten 
that  were  in  the  top  20  for  the  system,  although  the  Air  Force 
rate  was  much  higher  than  the  system  average.  The  rate  for  ATC 
44  is  attributed  to  Sacramento  which  showed  a  7.82  ATC  44  rate 
with  512  of  the  Air  Force  reject  volume.  ATC  44  indicates  tech¬ 
nical  data  was  not  supplied  for  an  item  requiring  technical  data 
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and  an  appropriate  justification  code  was  not  supplied.  ATC  14 
is  attributed  to  San  Antonio  ^nd  Warner  Robins  with  5.1%  and 
6.6%,  respectively.  San  Antonio  is  primarily  responsible  for  the 
reject  rate  for  ATC  19  in  the  Air  Force. 

The  30%  Marine  Corps  rate  for  ATC  30  is  attri¬ 
buted  to  an  interpretation  problem  regarding  the  use  of  Acquisi¬ 
tion  Advice  Code  J  (central  procure).  The  procedures  are  not 
clear  and  the  interpretation  by  SSR  submitters  is  varied.  The 
strict  interpretation  of  the  code  means  that  if  both  the  retail 
and  replenishment  quantity  fields  of  the  SSR  are  zero,  the  AAC 
should  be  J  and  if  the  AAC  is  J,  the  quantity  fields  should  be 
zero.  Analysis  of  the  usage  of  AAC  J  is  provided  later  on  in 
this  Chapter  under  data  element  usage.  Code  YU  Indicates  the  NSN 
is  not  in  DLSC  records  and  will  not  be  supported.  Either  there 
is  a  data  entry  problem  in  the  SSR  or  there  is  inadequate  DLSC 
screening  being  performed. 

The  previous  tables  and  charts  have  indicated 
that  some  of  the  total  system  high  frequency  rejects  are  being 
experienced  rather  uniformly  across  Components  and  activities 
within  Components.  Some  of  the  high  system  rejects  are  heavily 
influenced  by  a  particular  Component  or  even  a  single  activity 
within  jl  particular  Component  due  to  the  volume  of  business  in 
SSRs  conducted  by  the  Component  or  activity.  Some  activities  are 
experiencing  an  extremely  high  reject  rate  for  a  particular 
reject  code,  but  this  does  not  show  up  in  the  system  totals 
because  the  activity  business  volume  is  so  low.  This  does  not 
lessen  the  importance  of  the  reject  rate  to  the  particular  activ¬ 
ity  that  is  experiencing  the  condition,  and  should  not  be  ignored 
simply  due  to  sheer  statistical  volumes.  The  next  series  of 
charts  displays  the  top  rejects  by  activity  within  Component  to 
show  the  incidence  of  rejects  that  are  activity  significant,  but 
not  system  significant  due,  to  relative  statistical  volumes. 

Figure  1-73  presents  the  rejects  experienced 
within  the  Army.  Please  keep  in  mind  that  the  percentages  shown 

within  the  table  are  the  rates  experienced  by  the  individual 

activity  as  a  percentage  of  its  total  rejects  not  as  a  percentage 
of  the  system  total.  In  order  to  equate  the  rates  with  their 
relative  impact  on  system  totals,  the  relative  volume  of  business 
for  each  activity  within  Component  is  shown  at  the  activity 

columnar  heading  and  the  volume  of  business  of  the  Component  to 

system  total  is  shown  at  the  top  of  the  Component  column. 

There  was  quite  a  large  variance  among  the  top 
rejects  for  Army  activities.  But,  at  the  same  time,  the  volume 
of  business  varied  significantly  among  Army  activities.  Note 
that  ARRCOM  had  only  2.8%  of  the  Army  business  while  Army  had 
8.6%  of  the  system  total.  The  top  system  reject  (ATC  36) 
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appeared  in  the  top  ten  for  all  the  Army  activities.  But,  note 
the  52. 62  reject  rate  for  ATC  0?  for  CERCOM,  40. OX  for  ATC  52  for 
TARCOM  and  the  31.52  error  rate  for  ATC  39  for  TSARCOM.  These 
rates  are  attributed  to  activities  differences. 

The  Navy  reject  rates  are  shown  in  Figure  1-74. 
The  Navy  experienced  37. 72  of  the  system  business  so  Navy  reject 
rates  naturally  have  a  greater  system  total  impact  than  Army. 

For  the  same  reason  the  activity  rates  for  ASO  and  SPCC  in  the 
Navy  pretty  much  parallel  the  system  rejects  in  terms  of  ranking 
although  the  percentages  are  different.  Note  that  SPCC  dominates 
the  total  Navy  reject  percentages  because  of  the  large  percentage 
of  the  Navy  business  that  they  have.  Once  again,  the  reject  rates 
for  different  codes  are  attributable  to  activity  differences. 

TOP  TEN  REJECTS  FOR  NAVY 
(S1CC  Activity/Component ) 


SPCC 

86.32 

ASO 

13.72 

Navy 

37.72 

Rank 

ATC 

2 

ATC 

Z 

ATC 

2 

57 

28.2 

YS 

18.0 

57 

24.6 

YR 

18.6 

52 

17.4 

YR 

16.5 

07 

16.3 

36 

14.5 

07 

14.1 

36 

8.5 

34 

14.0 

36 

9.3 

52 

6.9 

08 

5.1 

52 

8.3 

34 

2.2 

YR 

4.2 

34 

3.8 

YC 

1.8 

19 

3.5 

YS 

2.7 

8 

45 

1.8 

YC 

3.1 

YC 

2.0 

9 

02 

1.6 

YR 

2.7 

YR 

1.8 

10 

42 

1.4 

04 

2.5 

45 

1.6 

Source:  DODSSK  Data  Collection;  Steady 

State  Population 


Figure  1-74 

The  three  largest  ALCs  in  terms  of  SSR  volume 
have  similar  ranking  among  themselves  and  with  the  total  system 
as  shown  in  Figure  1-75.  Rankings  for  OCALC  and  00ALC  are  dif¬ 
ferent  from  the  other  ALCs  and  between  themselves.  This  is 
attributed  to  the  extremely  low  volume  of  SSR  activity  they 
experienced  and  to  activity  differences. 
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The  Marine  Corps  has  only  one  SICC  SSR  submitter, 
the  Marine  Corps  Logistics  Support  Base,  Atlantic  (MCLSBA)  so  the 
information  contained  in  Figure  1-76  for  the  Marine  Corps  as  a 
Component  apply  to  their  activity  MCLSBA;  therefore,  no  further 
elaboration  will  be  provided  on  an  activity  basis. 

TOP  TEN  REJECTS  FOR  MARINE  CORPS 
(Activity /Component) 


Rank 

MCLSBA  - 

5.31 

ATC 

t 

1 

30 

30.0 

2 

32 

9.5 

3 

36 

9.0 

4 

52 

7.8 

5 

57 

6.9 

6 

YC 

5.8 

7 

34 

3.6 

8 

YU 

3.4 

9 

YR 

2.8 

10 

YK 

2.6 

Source:  DODSSR  Data  Collection; 

Steady  State  Population 

Figure  1-76 

The  previous  tables  showed  reject  rates  as  a 
function  of  the  SICC  submitter.  The  next  two  tables  will  show 
the  reject  rates  as  a  function  of  the  IMM  receiver.  Reject  codes 
for  the  Defense  Logistics  Agency  and  General  Services  Administra¬ 
tion  as  C1MM  activities  are  provided  in  Figure  1-77.  The  four  DLA 
Supply  Centers  are  also  listed  because  it  would  not  be  meaningful 
to  provide  information  for  DLa  and  GSA  as  Component  alone  and 
compare  with  the  system  total  because  DLA  accounts  for  96. 8Z  of 
the  advice  traffic,  while  GSA  accounts  for  only  1.5Z.  The  system 
figures  are  totally  dominated  by  DLA.  However,  comparing  the 
Centers  with  each  other  and  GSA  as  activities  is  more  meaningful. 

The  DLA  Centers  were  similar  in  their  reject 
patterns  among  themselves  and  with  the  system  total,  although 
there  are  some  activity  differences.  The  9.1Z  rate  for  ATC  30 
for  DCSC  is  significantly  above  the  system  average.  There  is  no 
evidence  to  Indicate  why  this  reject  should  be  higher  for  DCSC 
than  for  any  other  IMM.  The  8.5Z  rate  for  ATC  44  for  DGSC  is 
also  significantly  higher  than  the  system  average.  In  this 
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regard  it  is  pointed  out  that  DGSC  and  GSA  showed  a  higher  rate 
for  rejects  in  the  catalog/technical  data  reject  category  than 
other  IMMs.  Perhaps  this  is  a  function  of  the  commodity  area, 
since  these  two  IMMs  manage  similar  commodity  categories  than  is 
associated  with  GSA  and  other  DLA  Centers.  The  GSA  showed  an 
entirely  different  reject  pattern  than  DLA.  The  43.4%  reject  rate 
for  ATC  42  (duplicate  NSN  in  this  PCC  and  DOR,  same  item  serial 
number  appears  on  two  or  more  LISSRs  with  different  identifica¬ 
tion  data)  is  extremely  high  as  compared  to  the  system  average 
total  of  2.0%.  Since  GSA  receives  a  large  percentage  of  its  SSRs 
as  nonprovisioning  requests,  this  could  partly  explain  the  prob¬ 
lems  since  there  is  not  as  great  a  control  on  manually  generated 
nonprovisioning  SSRs  as  for  provisioning  SSRs.  There  was  also 
evidence  during  field  research  that  there  is  differing  interpre¬ 
tations  and  application  of  ATC  42  which  will  be  covered  in  Chapter 
V ,  Volume  I  . 


The  WIMM  statistics  in  Figure  1-78  also  showed 
ATC  36  as  the  number  one  reject  code.  Seven  of  the  top  ten  reject 
codes  for  WIMM  were  common  to  CIMM  although  the  rankings  were 
different  after  the  first  rank.  The  percentages  of  WIMM  rejects 
are  relative  to  the  WIMM  volume  which  is  extremely  small  in  com¬ 
parison  with  the  CIMM  volume. 

f .  Followup/Response  Analysis.  The  SSR  Procedures  spec¬ 
ify  that  a  submitter  of  an  SSR  may  follow  up  for  advice  on  the 
status  of  an  SSR  when  advice  has  not  been  received  from  the  IMM. 
Followup  may  be  made  for  initial  advice  on  the  support  decision 
of  a  request  or  for  advice  on  the  assignment  of  an  NSN  for  a  part 
numbered  SSR  that  has  been  accepted  for  support  by  an  IMM. 

( 1 )  Relationships  Between  SSR  Requests/Followups/ 

Responses 


Figure  1-79  shows  the  relationships  of  followups 
to  request  volumes  for  SSR  submitters. 

It  appears  that  those  Components  and  activities 
that  have  automated  systems  generally  tend  to  generate  more  fol¬ 
lowups  than  those  with  manual  systems.  At  the  time  of  the  data 
collection,  the  Army,  SPCC  in  the  Navy  and  the  Marine  Corps  were 
using  manual  systems  for  the  generation  of  followups;  therefore, 
their  percentages  of  followups  were  much  lower  than  their  request 
rates.  The  Air  Force  has  an  automated  system  for  creation  of 
followups.  The  SSR  Procedures  allow  the  IMM  25  days  from  the 
date  of  receipt  of  an  SSR  to  provide  initial  advice  and  60  days 
from  date  of  receipt  of  an  SSR  to  give  NSN  advice.  The  proce¬ 
dures  specify  that  the  SICC  may  followup  35  days  after  submission 
of  the  SSR  for  initial  advice  or  70  days  for  NSN  advice.  The  Air 
Force  system  causes  a  followup  to  be  generated  using  the  date  of 
request  in  the  SSR  as  the  starting  point.  The  DOR  is  the  date 
the  SSR  was  created  by  the  computer.  The  SSR  must  then  be  for¬ 
warded  to  the  functional  organization  element  for  matching  with 
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RE QUEST /FOLLOWUP /RESPONSE  RELATIONSHIPS  FOR  SUBMITTER 
(Percent  Transaction  Volume  by  Transaction  Type) 


Transaction  Type  t 

SICC 

Request 

Followup 

Response 

ARRCOM 

0.2% 

0.2% 

0.2% 

CERCOM 

2.3 

0.0 

0.0 

MIRCOM 

0.6 

0.0 

0.0 

TARCOM 

1.0 

0.1 

0.1 

TSARCOM 

A. 8 

0.1 

0.1 

Army 

8.9% 

0 .  A% 

0 .  A% 

ASO 

8.6% 

25.3% 

A. 8% 

SPCC 

25.6 

0.0 

0.0 

Navy 

3A .  2  % 

25.3% 

A. 8% 

OCALC 

0.3% 

0.0% 

0.0% 

OOALC 

1.8 

5.8 

2.0 

SAALC 

9.9 

18.3 

27.5 

SMALC 

23.  A 

29.7 

AO. 9 

WRALC 

8.8 

19.5 

22.7 

Air  Force 

AA.2% 

73.3% 

93.1% 

MCLSBL 

5.2% 

0.6% 

1.1% 

MC 

5.2% 

0.6% 

1.1% 

EGICP 

0.2% 

0.0% 

0.0% 

S1CP 

0.0 

0.0 

A1CP 

0.0 

0.0 

0.0 

CG 

0.3% 

0.0% 

0.0% 

Other 

7.2% 

0.  A% 

0.6% 

Total 

100.0% 

100.0% 

100.0% 

Source:  OOOSSR  Data  Collection;  Steady  State  Population 


Figure  1-79 
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drawings  and  packaging  the  item  for  mailing.  The  combination  of 
internal  wait  and  processing  time  prior  to  mailing  the  SSR,  the 
actual  intransit  time  for  mailing  and  the  internal  processing 
time  at  the  IMM  can  cause  advice  to  be  received  after  35  days  from 
the  creation  of  an  SSR  in  the  Air  Force;  resulting  in  the  creation 
of  followups  because  advice  has  not  been  received  within  35  days 
of  the  DOR.  This  combination  of  circumstances  causes  the  Air 
Force  to  have  a  disproportionate  number  of  followups  in  relation 
to  the  other  Components.  The  differences  in  followup  and  response 
rates  for  SPCC  in  the  Navy  and  the  Air  Force  are  attributed  to  a 
combination  of  loss  of  transactions  to  the  data  collection  and 
the  cutoff  points  for  the  data  collection,  and  use  of  CXI  advice 
transactions  in  place  of  a  CX4  response. 

Figure  1-80  provides  the  relationships  for  IMMs 
as  receivers  of  SSRs.  The  table  includes  figures  for  both  CIMM 
and  WIMM  items.  The  differences  are  not  quite  so  dramatic  as  for 
submitters.  However,  there  does  appear  to  be  a  common  thread  as 
relates  to  the  differences  between  automated  and  manual  systems. 
The  manual  systems  of  the  Services  for  W1MM  items  and  GSA  for  CIMM 
items  seem  to  receive  a  disproportionate  number  of  followups  in 
relation  to  the  requests  that  they  receive.  The  number  of  re¬ 
sponses  however  seem  to  be  signficantly  lower  than  their  follow¬ 
ups  indicating  a  delay  in  providing  a  response,  or  lack  of  a  re¬ 
sponse,  or  use  of  a  CXI  in  place  of  a  CX4 .  During  field  research, 
it  was  learned  that  some  of  the  Services  were  responding  to  fol¬ 
lowups  by  letter  rather  than  using  advice  cards  as  prescribed  by 
the  SSR  system.  Some  are  using  CXI  advice  transactions  in  place 
of  response  transactions.  The  volume  of  followups  for  DLA  seems 
to  be  rather  low  as  compared  to  the  number  of  responses  provided. 
It  is  believed  that  some  of  the  followups  sent  might  not  be  in¬ 
cluded  in  the  data  collection. 

( 2 )  Response  Analysis 

Figure  1-81  provides  statistics  on  the  categories 
of  advice  received  by  SICCs  to  their  followups.  The  data  is  shown 
by  Component  since  the  volume  is  so  low  on  an  activity  basis, 
except  for  Air  Force.  The  rate  for  No  Record  of  the  original  SSR 
is  much  too  high.  This  rate  suggests  that  the  submitters  are 
following  up  too  soon  or  there  is  a  loss  of  SSR  records  being 
transmitted  from  the  SICC  to  the  IMM.  The  procedures  currently 
call  for  the  SSR  to  be  mailed.  Advice  transactions  such  as  fol¬ 
lowups  and  responses  may  either  be  mailed  or  sent  over  AUTODIN. 

The  shorter  transmission  time  for  the  followups  could  also  cause 
the  followup  to  be  received  prior  to  the  original  request  result¬ 
ing  in  a  "no  record”  condition.  Logic  would  seem  to  dictate  that 
the  "pending"  condition  rate  should  be  higher.  If  a  SICC  has  not 
received  advice  it  would  seem  that  the  SSR  was  delayed  and  would 
still  be  pending  when  a  followup  was  forwarded.  About  53%  of  the 
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REQUEST/FOLLOWUP/RESPONSE  RELATIONSHIPS  POR  RECEIVER 
(Percent  Transaction  Volume  by  Transaction  Type) 


Transaction  Type  j 

IMM 

mnsmsam 

Followup 

Response 

ARRCOM 

0.12 

0.8% 

0.6% 

CERCOM 

0.3 

0.3 

0.0 

MIRCOM 

0.1 

0.1 

0.0 

TARCOM 

0.2 

0.6 

0.1 

TSARCOM 

0.1 

0.4 

0.1 

Army 

00 

• 

O 

2.2% 

0.8% 

ASO 

0.3% 

1.8% 

— 

SPCC 

0.4 

2.6 

■Bm 

RHHi 

0.7% 

4.4% 

0.1% 

OCALC 

0.1% 

0.5% 

mem 

OOALC 

0.1 

0.4 

SAALC 

0.1 

0.6 

SMALC 

0.1 

0.2 

URALC 

0.4 

Air  Force 

0.6% 

2.1% 

0.2% 

MCLSBL 

0.1% 

0.4% 

0.0% 

MC 

0.1% 

0.4% 

N 

O 

• 

o 

DCSC 

9.2% 

5.3% 

6.7% 

DESC 

53.0 

43.9 

46.5 

DGSC 

9.8 

3.0 

3.9 

DISC 

22.7 

32.5 

41.1 

DL.A 

94.7% 

a* 

r^. 

• 

•4* 

00 

Cs| 

• 

oo 

o> 

GSA 

2.4% 

6.0% 

0.7% 

Other 

0.7% 

0.2% 

0.0% 

Total 

100.0% 

100.0% 

100.0% 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-80 
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time  a  support  advice  decision  (accept,  reject,  offer)  has  already 
been  made  when  the  followup  is  received.  The  question  then,  arises 
as  to  whether  the  followup  is  being  received  too  soon,  or  whether 
the  responses  are  not  being  properly  recorded  in  the  control  files 
of  the  SICC. 

CX4  RESPONSE  TO  FOLLOWUPS  BY  SUBMITTER  COMPONENT 

(Row  Percent) 


SICC 

|  Advice  Category  i 

Accept 

Offer 

Pending 

mumm 

No  Record 

Army 

40. 7% 

0.0% 

11.1% 

40.7% 

Navy 

65.2 

2.2 

10.4 

3.2 

Air  Force 

33.2 

3.2 

31.0 

H  1 

17.9 

MC 

60.0 

7.1 

1.4 

10.1 

21.4 

Total 

35.2% 

3.2% 

29.4% 

15.0% 

17.2% 

Source;  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-81 

Responses  to  followups  sent  out  by  IMMs  are 
shown  in  Figure  1-82.  The  Pending  and  No  Record  rates  for  GSA 
appear  to  be  more  in  line  with  expected  responses  than  for  the 
other  Components.  The  accept  rate  for  the  Air  Force  indicates 
that  either  they  are  receiving  followups  too  soon  or  they  are 
using  the  response  transaction  to  provide  "original”  advice.  The 
SSR  Procedures  specify  that  a  response  to  a  followup  will  consist 
of  existing  advice  previously  provided  and  recorded  in  the  suspense 
file  of  the  IMM,  pending  advice  if  there  is  a  record  of  the  orig¬ 
inal  request  with  no  record  of  advice,  or  a  No  Record  response 
if  there  is  no  record  of  the  original  SSR  in  the  suspense  file  of 
the  IMM.  The  procedures  seem  to  imply  that  "file  status”  will  be 
provided  in  a  CX4  response  to  an  SSR  followup.  If  no  support 
decision  is  in  the  file  and  a  Pending  Advice  was  provided  by  the 
response,  then  a  CXI  advice  card  would  follow  with  the  support 
decision.  The  procedures  do  not  discuss  or  differentiate  between 
the  use  of  a  CXI  in  place  of  a  CX4  or  a  CX4  in  place  of  a  CXI, 
although  either  case  is  not  excluded  and  can  occur  in  practice. 

It  would  seem  that  if  a  support  decision  is  imminent,  either  a 
CXI  or  CX4 ,  but  not  both  would  be  used,  with  a  convention  to 
Indicate  that  the  advice  accomplishes  both  the  providing  of  sup¬ 
port  advice  and  responds  to  the  followup  transaction. 
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CX4  RESPONSE  TO  FOLLOWUP  BY  RECEIVER  COMPONENT 
(Row  Percent) 


Advice  Category 


IMM 

Accept 

Offer 

Pending 

Reject 

No  Record 

Army 

97.9% 

0.0% 

0.0% 

wmmm 

2.1% 

Navy 

50.0 

0.0 

0.0 

0.0 

Air  Force 

83.3 

0.0 

0.0 

0.0 

MC 

100.0 

0.0 

0.0 

0.0 

DLA 

34.8 

3.3 

29.3 

17.5 

GSA 

11 . 1 

0.0 

88.9 

o 

• 

o 

0.0 

Total 

35.2% 

3.2% 

29.4% 

15.0% 

mam 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-82 

Because  of  the  predominance  of  DLA  in  terms  of 
the  volume  of  requests  received,  and  by  the  same  token  the  number 
of  followups  received,  Figure  1-83  was  generated  to  determine 
if  there  was  any  activity  differences  among  the  Defense  Supply 
Centers  >  Based  upon  the  variances  shown,  there  does  appear  to  be 
some  significant  activity  differences  among  the  Centers.  The 
lower  instance  of  "No  Record"  advice  for  DCSC  would  seem  to  indi¬ 
cate  better  control  procedures  or  that  SSRs  that  had  been  mailed 
were  being  introduced  to  the  computer  more  efficiently.  It  would 
appear  that  in  many  cases  DCSC  has  made  a  support  decision,  but 
is  receiving  the  followup  too  soon  or  the  advice  is  not  being 
properly  controlled  and  recorded  by  the  SICC  receiving  the  origi¬ 
nal  advice.  The  high  "No  Record"  rates  for  the  other  Centers  are 
attributed  to  a  combination  of  early  followups,  slow  mail  trans¬ 
mission  for  requests  as  opposed  to  more  rapid  transmission  of 
followups  over  AUTODIN,  and  internal  delays  in  introducing  SSRs 
into  the  suspense  files  of  the  IMM. 

CX4  RESPONSE  TO  FOLLOWUPS  BY  DEFENSE  SUPPLY  CENTER 

(Row  Percent) 


CIMM 

Advice  Category 

Accept 

Offer 

Pending 

■LULUfli 

No  Record 

DCSC 

44.3% 

0.0% 

28.6% 

14.1% 

13.0% 

DESC 

37 . 8 

5.7 

27.7 

20.8 

8.0 

DGSC 

45.1 

0.4 

28.2 

14.9 

11.4 

DISC 

28.8 

1.3 

31.3 

9.0 

29.6 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-83 
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The  17.2%  of  No  Record  responses  was  considered 
too  high  to  be  acceptable.  Figure  1-84  was  generated  to  deter¬ 
mine  If  there  was  any  Component  or  activity  Influencing  the  high 
frequency  of  No  Record  actions.  The  statistics  are  shown  for  the 
total  population  of  data  (Main)  and  for  the  first  half  (Transi¬ 
tion)  and  for  the  second  half  (Steady  State)  of  the  data  collec¬ 
tion.  The  Air  Force  totally  dominates  the  number  of  No  Record 
responses  from  a  submitter  standpoint.  This  is  due  not  only  to 
the  number  of  followups  sent  due  to  the  automated  system  in  the 
Air  Force,  but  to  the  practice  of  using  the  date  of  the  request 
as  opposed  to  the  date  of  submission  to  generate  followups. 


This  practice  causes  a  followup  to  be  generated 
approximately  two  weeks  early  than  if  the  date  of  submission  were 
used.  The  number  of  followups  would  be  reduced  by  the  number  of 
advice  transactions  that  might  have  been  received  during  the  two 
week  timeframe.  The  early  followups  coupled  with  the  mailing  of 
the  SSR  and  use  of  AUTODIN  for  the  followup  combine  to  cause  the 
followup  to  be  introduced  to  the  suspense  file  prior  to  the  orig¬ 
inal  request  being  recorded.  This  results  in  a  No  Record  response 
being  sent  on  the  basis  of  the  followup.  The  Air  Force  then 
generates  another  SSR  on  the  basis  of  the  No  Record  response. 

This  SSR  duplicates  the  previous  one,  except  for  the  date  of  re¬ 
quest.  If  the  first  request  is  then  received  after  the  followup 
it  will  be  processed  and  advice  provided.  If  the  second  SSR  is 
received  and  it  falls  into  a  different  cycle,  which  it  probably 
will,  it  too  will  also  be  processed  with  the  possibility  of  double 
consideration  of  the  quantitative  requirements,  contingent  upon 
whether  the  SSR  is  for  an  NSN  item  or  part  numbered  item  and  the 
method  of  stockage  determination  made  upon  the  first  SSR  that  was 
processed.  Clearly  there  needs  to  be  some  change  made  on  both 
the  sending  and  receiving  sides  to  correct  these  conditions. 

CX4  NO  RECORD  RESPONSE  BY  SUBMITTER 
(Column  %  ATC  66  by  Population  Period) 


SICC 

Population 

Main 

Transition 

Steady  State 

Army 

1.0% 

2.0% 

1.0% 

Navy 

2.3 

6.3 

0.9 

Air  Force 

95.7 

91.1 

96.8 

MC 

0.9 

0.4 

1.3 

Other 

0.1 

0.2 

0.0 

Total 

100.0% 

100.0% 

100.0% 

Source:  DODSSR  Data  Collection 


No  Record  responses  by  receiver  are  shown  In 
Figure  1-85.  The  higher  race  for  DLA  as  opposed  to  Che  Services 
is  attributed  to  the  volume  of  C1MM  traffic  received  by  DLA  as 
compared  with  the  small  volume  of  WIMM  traffic  the  Services  re¬ 
ceive.  Service  volumes  are  WIMM;  DLA  and  GSA  volumes  are  CIMM. 
Except  for  the  steady  state  period,  DLA's  No  Record  advice  is 
lower  thaa  its  request  volume.  The  3.7X  rate  for  the  Navy  in  the 
total  population  and  5. OX  for  GSA  in  the  transition  periods  are 
much  higher  than  the  proportional  number  of  requests  that  they  re¬ 
ceive.  The  dropoff  in  the  steady  state  period  is  attributable  to 
the  number  of  followups  sent  during  the  conversion  to  the  new  pro¬ 
cedures  and  the  institution  of  associated  new  processing  systems. 
The  high  rate  for  DLA  in  the  steady  state  period  is  attributed  to 
a  combination  of  early  followups  by  SICCs,  use  of  mail  for  requests 
and  AUTODIN  for  followups,  and  delayed  entry  of  the  SSR  into  the 
suspense  file  by  the  1MM. 

CX4  NO  RECORD  RESPONSE  BY  RECEIVER 
(Column  X  ATC  66  by  Population  Period) 


IMM 

Population 

Main 

Transition 

Steady  State 

Army 

0.6X 

1.8X 

0.1Z 

Navy 

3.7 

0.9 

0.0 

Air  Force 

0.2 

0.5 

0.0 

MC 

0.1 

0.0 

0.0 

DLA 

93.3 

91.8 

99.9 

GSA 

2.0 

5.0 

0.0 

Other 

.  0.1 

0.0 

0.0 

Total 

100. OX 

100. OX 

100. OX 

Source:  DODSSR  Data  Collection 


Figure  1-85 

5.  Transaction  Chain  Analysis.  Chapter  IV,  Volume  I,  des¬ 
cribed  the  different  types  of  SSR  transaction  record  types,  and 
indicated  how  these  transactions  are  combined  into  SSR  packages. 
Document  Identifier  Codes  (DICs)  identify  the  basic  transaction 
types.  Type  of  Change  Codes  (TCCs)  indicate  whether  the  transac¬ 
tion  is  an  initial  or  change  transaction.  Transaction  Codes 
called  Action  Taken  Codes  (ATCs)  further  define  specific  actions 
that  have  been  taken  on  an  SSR  and  are  used  in  advice  cards. 

When  an  SSR  is  forwarded  by  a  SICC  to  an  IMM  it  initiates  a 
series  of  events  that  culminate  in  the  final  acceptance  or  rejec¬ 
tion  of  supply  support  for  an  item.  The  events  in  the  SSR  chain 
are  identified  by  a  combination  of  the  DIC,  TCC  and  ATC.  The 
Individual  events  are  tied  to  each  other  through  a  series  of 
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control  elements  that  act  as  links  in  the  chain  to  permit  the 
relation  of  one  event  to  another.  Because  of  the  number  of  dif¬ 
ferent  types  of  events  and  the  number  of  different  combination  of 
events  that  can  occur,  the  study  group  decided  to  perform  an 
analysis  of  SSR  transaction  chains  to  see  what  combinations  were 
occurring  in  practice  and  what  was  the  net  effect. 

a .  SSR  Chain  of  Events 

( 1 )  Event  Classification 

Paragraph  C.4.  of  this  Chapter  provided  a  des¬ 
cription  and  analysis  of  the  different  types  of  advice  provided 
on  SSRs.  Figure  1-33  categorized  ATCs  into  ATC  categories.  This 
table  was  used  in  conjunction  with  the  breakdown  of  transaction 
types  provided  in  Chapter  IV,  Volume  I,  to  classify  SSR  transac¬ 
tions  into  events.  Figure  1-86  reflects  the  results  of  this 
classification. 

TYPES  OF  EVENTS 


Type 

1-Digit 

2-Digit 

3-Digit 

Request 

0 

1  to  5 

1  to  3 

Accept 

1 

0 

1  to  5 

Offer 

2 

0 

1  to  2 

Status 

3 

0 

1  to  3 

Re  ject 

4 

1  to  7 

Alpha / 

Numeric 

Reply 

5 

1  to  2 

1  to  2 

Followup 

6 

0 

0 

Response 

7 

o 

1  to  2 

Source:  DOOSSR  Data  Processing;  Specification  No.  17 

Figure  1-86 

Supply  support  request  transactions  were  classi¬ 
fied  into  eight  different  types  of  events.  A  series  of  three  digit 
codes  were  assigned  to  the  different  types  of  events  to  permit 
computer  analysis  of  SSR  chains  and  the  relationship  of  events  in 
a  chain.  The  first  position  of  the  code  (1-DIGIT)  was  used  to 
identify  the  basic  events.  Since  a  chain  commences  with  a  request, 
a  numeric  zero  was  used  to  identify  a  request  and  other  numeric 
digits  from  1  to  7  were  used  to  Identify  events  that  represented 
subsequent  actions  taken  upon  the  original  request.  Numbers  were 
assigned  in  ascending  sequence  to  the  events  in  the  preferred  and 
logical  order  of  occurrence. 
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Some  of  the  evtnti  wars  divided  Into  on*  or  aora 
subcategories  within  the  basic  event,  so  the  second  and  third 
digits  were  used  to  reflect  thle  cetegorlsetion.  For  example  an 
SSR  can  be  an  initial  or  change  request  for  an  NSN  or  part  nua- 
bered  item  sent  to  a  CIMM  or  WIMM.  The  categorisation  using  the 
codes  is  shown  below: 


example  1 

1  -  DIGIT 

2  -  DIGIT 

3  -  DIGIT 


Code  0  is  assigned  to  indicate  that  the  basic 
event  is  a  request  transaction. 

Code  1  is  assigned  to  indicate  a  request  for  an 
NSN  itea  froa  a  CIMM. 

Code  1  is  assigned  to  indicate  an  initial  sub¬ 
mission  . 


The  codification  indicates  the  request  of  an  NSN  itea  froa  a 
CIMM. 


Example  2 


DIGIT 

DIGIT 

DIGIT 


Code  0  is  assigned  to  indicate  that  the  basic 
event  is  a  request  transaction. 

Code  5  is  assigned  to  indicate  a  request  for  a 
part  numbered  item  from  a  WIMM. 

Code  2  is  assigned  to  indicate  a  deletion  without 


replacement  of  a  previous  request. 


The  same  codification  system  was  used  to  identify  the  other  types 
of  events  including  the  identification  of  reject  advice  into  the 
subcategories  previously  shown  in  Figure  1-33  and  also  to  indicate 
the  specific  rejection  within  the  reject  subcategory. 


(2)  Control  Elements.  There  are  a  number  of  data 


elements  used  to  control  the  processing  of  an  SSR  from  both  the 
submitter  (SICC)  and  receiver  (IMM)  processing  aspects.  These 
data  elements  are  used  to  control  and  relate  the  processing  of 
all  SSR  events  from  the  initial  request  until  final  acceptance  or 
rejection  of  the  SSR.  Control  elements  include: 


(a)  Activity  Code  (From)  -  The  activity  sub¬ 
mitting  the  SSR  transaction. 


(b)  Activity  Code  (To)  -  The  activity  receiving 
the  SSR  transaction  for  processing. 

(c)  Provisioning  Control  Code  (PCC)  -  A  code 
assigned  by  a  provisioning  activity  to  a  provisioning  project  to 
ensure  that  data  exchanges  are  related  to  the  same  end  itea  in  a 
provisioning  package. 


(d)  Item  Serial  Number  (ISN)  -  A  code  assigned 
to  an  individual  line  item  in  a  provisioning  package  to  identify 
an  item  of  supply  (NSN,  part  number,  PSCN). 

(e)  Date  of  Request  (DOR)  -  Date  on  which  the 
request  transaction  is  sent  from  the  SICC  to  the  IMM.  It  is 
repeated  in  transactions  for  subsequent  events  relating  to  the 
initial  request. 


(f)  Date  of  Advice  (DOA)  -  The  date  on  which  an 
advice  transaction  is  sent  from  an  IMM  to  a  SICC  or  from  a  SICC 
to  an  IMM. 


(g)  Type  of  Change  Code  (TCC)  -  Indicates 
whether  an  SSR  is  an  original  or  change  transaction. 

(h)  Document  Identifier  Code  (PIC)  -  Identifies 
the  type  of  SSR  transaction  (Program,  Line  Item  Request  or  Advice) 

(3)  Symbolic  Chain  of  Events.  Figure  1-87  provides 
a  symbolic  chain  of  events  that  can  be  used  to  show  the  relation¬ 
ship  of  transaction  events  and  control  elements  described  above. 
The  symbols  represent  the  eight  different  types  of  events  that 
can  occur.  The  control  elements  represent  the  links  that  tie  the 
events  in  the  chain  together.  Although  only  one  control  element 
is  shown  per  link,  all  of  the  control  elements  are  needed  to  tie 
the  different  events  together.  The  chain  must  start  out  with  a 
request  represented  by  a  Code  0  Event.  After  the  request,  events 
can  occur  in  any  one  of  a  number  of  combinations.  Events  can 
occur  more  than  once  in  a  chain  and  can  occur  in  different  orders. 
In  the  symbolic  chain  shown,  the  sequence  of  events  is  as  follows: 


Event 

1  -  Code 

0  -  Request 

for  Supply 

Support . 

Event 

2  -  Code 

3  -  Advice  transaction 
Event  1 . 

providing  status 

on 

Event 

3  -  Code 

2  -  Offer  of 

alternate 

or  substitute  on 

Event 

Event 

4  -  Code 

5  -  Reply  to 

the  Offer 

in  Event  3. 

Event 

5  -  Code 

6  -  Followup 

for  NSN  advice. 

Event 

6  -  Code 

?  -  The  event  is  unidentifiable  or  missing. 

possibly  due  to  a  problem  with  a  control 
e lement . 


Event  7  -  Code  7  -  Response  to  followup  on  Event  5. 


117 


Event  8  -  Code  4  -  Rejection  of  SSR,  possibly  the  uniden¬ 
tified  Event  6. 

Event  9  -  Code  1  -  Acceptance  of  SSR. 

( 4 )  Symplified  Chain  of  Events 

The  symbolic  chain  of  events  in  Figure  1-87  was 
depicted  to  show  how  the  eight  different  type  of  events  relate  to 
each  other  and  that  these  events  could  be  repetitive,  duplicative, 
missing  or  occur  in  varying  order  in  a  chain.  Figure  1-88  provides 
four  different  chain  types  of  a  more  simplified  nature.  These 
four  types  do  not  represent  all  the  possibilities,  but  those  that 
would  be  expected  to  occur  the  most  frequently  or  those  that  one 
would  prefer  to  occur. 

The  most  desirable  chain  from  the  supply  support 
standpoint  would  be  the  second  chain  from  the  top,  the  one  with 
the  straight  line.  This  chain  represents  a  request  followed  by 
an  acceptance  with  or  without  an  NSN.  The  chain  at  the  top  repre¬ 
sents  a  request  for  a  part  numbered  item  followed  by  an  initial 
acceptance  followed  by  an  NSN  notification.  The  third  chain  rep¬ 
resents  a  request  followed  by  an  offer  that  is  accepted  by  the 
S1CC  with  an  NSN  notification  following  if  the  offered  item  is  a 
part  numbered  item.  The  bottom  chain  shows  a  request  that  has 
been  rejected,  resubmitted  followed  by  an  offer  by  the  IMM, 
acceptance  of  the  offer  by  the  SICC  and  followed  by  an  NSN  advice 
if  the  offer  was  a  part  numbered  item. 

A  review  of  a  printout  of  SSR  transactions  indi¬ 
cated  that  there  were  chains  with  a  number  of  transactions  in 
them  occurring  in  various  orders .  Computer  programs  were  devel¬ 
oped  using  the  chain  codes  described  previously  to  determine  the 
transaction  frequency  in  chains  and  the  frequency  of  occurrence 
of  different  types  of  chain  patterns.  It  should  be  noted  that 
the  symbolic  chain  and  simplified  chains  depicted  previously  can 
be  classified  as  chain  patterns  and  examined  to  determine  the 
frequency  of  occurrence  and  the  net  effect  of  their  occurrence. 

The  statistics  shown  in  this  section  represent  the  results  of 
this  computer  analysis. 

b .  Transactlon/Chaln  Frequency 

The  previous  section  described  the  makeup  of  SSR 
chains  and  indicated  that  transactions  could  occur  in  different 
combinations  and  frequency  of  occurrence  in  chains.  The  following 
frequency  distributions  were  prepared  to  determine  the  number  of 
transactions  that  were  occurring  per  chain  in  actual  practice. 

The  transition  population  was  chosen,  because  is  was  the  only 
population  that  did  not  have  transactions  attributable  to  the  old 
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SSR  CHAIN  OF  EVENTS 
(SIMPLIFIED) 


Figure  1-88 


r 


system  and  had  enough  time  after  a  request  was  generated  to  per¬ 
mit  completion  of  the  chain.  Frequency  distributions  were  pre¬ 
pared  for  transactions  beginning  with  an  NSN,  part  number,  or 
PSCN  request.  Chains  had  to  begin  with  an  initial  provisioning 
request  transaction  to  be  included  in  the  analysis.  Chains  that 
began  with  other  than  a  request  transaction  were  excluded  from 
this  analysis.  If  a  chain  did  not  begin  with  a  request  it  was 
considered  an  invalid  chain.  Nonprovisioning  chains  are  dif¬ 
ficult  to  build  because  the  control  elements  are  duplicative. 

(1)  CXA  Chains 

Figure  1-89  provides  a  ranked  frequency  distribu¬ 
tion  for  chains  beginning  with  an  NSN  request. 

RANK  AND  FREQUENCY  DISTRIBUTION  OF 
NUMBER  OF  TRANSACT IONS / CHAIN  FOR  PIC  CXA 


Rank 

Number 

of 

Trans¬ 

actions 

Gross 

Number 

of 

Chains 

Net 

Number 

of 

Chains 

X  of  Gross 
Total  of 

CXA  Chains 

Cum  X  of 
Gross 

Total 

CXA  Chains 

2 

41,361 

11 

75.1 

75.1 

4 

5,327 

100 

9.7 

84.8 

3 

3,178 

49 

5.8 

90.6 

1 

2,568 

1 

4.7 

95.3 

5 

1,051 

103 

1.9 

97.2 

6 

869 

108 

1.6 

98.8 

7 

306 

68 

0.6 

99.4 

!  8 

8 

269 

57 

0.5 

99.9 

KB 

9 

79 

29 

0.1 

100.0 

KB 

11 

21 

15 

H9 

10 

12 

11 

mi 

12 

10 

8 

mm 

13 

5 

5 

m 

14 

1 

1 

16 

1 

1 

16 

30 

1 

1 

Total 

..  5  5_,0  5_9_, 

568 

Source:  DODSSR  Data  Collection;  Transition  Population 


Figure  1-89 

The  most  desired  pattern  for  a  stock  numbered 
chain  would  be  for  a  request  followed  by  an  acceptance;  in  other 
words  a  two  transaction  chain.  There  were  75X  of  the  chains  with 
only  two  transactions.  However,  this  does  not  indicate  that  each 
of  the  requests  were  accepted.  There  are  only  five  possible  com¬ 
binations  for  acceptance  of  a  request,  but  there  are  11  different 
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types  (net)  of  these  chains  indicating  there  were  some  offers  and 
rejections  in  these  two  transaction  chains.  Over  20%  of  all  the 
chains  had  over  two  transactions  and  4.7%  of  the  chains  had  over 
four  transactions.  Out  of  55,059  different  NSN  request  chains 
there  were  568  different  types  of  patterns.  This  is  caused  by 
the  number  of  different  types  of  transactions  (request,  offer, 
reject)  and  the  number  of  different  ATCs  (70)  that  can  be  used  in 
advice  transactions.  Note  that  some  of  the  chains  had  as  many  as 
30  transactions  involved.  The  more  transactions  that  occur  in  a 
chain  indicate  that  the  same  basic  request  is  being  handled  more 
than  once.  The  more  times  that  this  occurs,  the  longer  it  will 
take  to  complete  the  chain  and  supply  support  is  delayed  accord¬ 
ingly.  The  cost  to  process  a  request  is  also  increased  when  a 
request  requires  repetitive  handling. 

(2)  CXB  Chains 


1-90. 


Part  numbered  request  chains  are  shown  in  Figure 


RANK  AND  FREQUENCY  DISTRIBUTION  OF 
NUMBER  OF  TRANSACTIONS/CHAIN  FOR  PIC  CXB 


Rank 

Numbe  r 
of 

Trans¬ 

actions 

Gross 
Numbe  r 
of 

Chains 

Net 

Number 

of 

Chains 

%  of  Gross 
Total  of 

CXB  Chains 

Cum  %  of 
Gross 

Total 

CXB  Chains 

1 

2 

21,883 

12 

41.6 

41.6 

2 

3 

12,085 

87 

23.0 

64.6 

3 

4 

7,702 

220 

14.7 

79.3 

4 

5 

3,514 

292 

6.7 

86.0 

5 

1 

2,650 

1 

5.0 

91.0 

6 

6 

2,237 

273 

4.3 

95.3 

7 

7 

1,465 

202 

2.8 

98.1 

8 

8 

822 

132 

1.6 

99.7 

9 

9 

106 

63 

0.2 

99.9 

10 

10 

41 

21 

0.1 

100.0 

11 

11 

27 

11 

0.1 

12 

14 

4 

4 

13 

12 

3 

3 

14 

2 

2 

15 

1 

1 

16 

1 

1 

Total 

52,543 

1,325 

Source:  DOSSR  Data  Collection;  Transition  Population 


Figure  1-90 
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The  number  of  gross  CXB  chains  approximates  Che 
number  of  CXA  chains*  But  please  note  that  there  are  over  2.3 
times  as  many  different  net  part  numbered  chains  than  stock  num¬ 
bered  chains.  This  indicates  that  CXB  chains  are  more  complex. 
Only  41. 6Z  of  the  CXB  chains  had  two  transactions  as  compared  to 
75. IX  of  the  CXAs,  and  15. 7%  had  over  four  transactions  as  com¬ 
pared  to  4.7%  for  CXA. 

(3)  CXC  Chains 

Chains  for  PSCN  items  are  shown  in  Figure  1-91. 

RANK  AND  FREQUENCY  DISTRIBUTION  OF 
NUMBER  OF  TRANSACTIONS /CHAIN  FOR  PIC  CXC 


Rank 

Numbe  r 
of 

Trans¬ 

actions 

Gross 

Number 

of 

Chains 

Net 

Number 

of 

Chains 

%  of  Gross 
Total  of 

CXC  Chains 

Cum  X  of 
Gross 

Total 

CXC  Chains 

1 

3 

28 

r~ 

3 

22.8 

22.8 

2 

2 

23 

4 

18.7 

41.5 

3 

4 

22 

8 

17.9 

59.4 

4 

9 

16 

2 

13.0 

72.4 

5 

5 

10 

4 

8.1 

80.5 

6 

6 

10 

5 

8.1 

88.6 

7 

1 

8 

1 

6.5 

95.1 

8 

7 

5 

5 

4.1 

99.2 

9 

8 

1 

1 

0.8 

100.0 

Total 

123 

33 

Source:  DOOSSR  Data  Collection;  Transition  Population 


Figure  1-91 

The  basic  pattern  for  this  chain  should  be 
request,  initial  accept,  NSN  advice.  The  vast  majority  of  the 
chains  should  be  three  transactions,  and  over  34%  had  over  four 
transactions.  These  are  items  on  which  standardization  actions 
have  already  been  completed  and  a  stock  number  will  be  assigned 
immediately  upon  request,  but  these  chains  are  more  complex  than 
for  part  numbered  items. 

(4)  CXA/B/C  Chains 

Chains  for  all  types  of  C1MM  requests  are  shown 

in  Figure  1-92. 
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There  were  1,926  different  types  of  chains  during 
the  entire  period.  Almost  5%  of  the  chains  had  only  one  transac¬ 
tion  indicating  no  advice,  although  the  data  collection  allowed 
four  months  for  a  reponse  for  the  last  transaction  in  the  period. 
Over  10%  of  the  chains  had  over  four  transactions.  Chains  with 
six  or  more  transactions  accounted  for  5.9%;  seven  and  up  had  3%; 
eight  and  up  1.3%. 

RANK  AND  FREQUENCY  DISTRIBUTION  OF 
NUMBER  OF  TRANSACTIONS /CHAIN  FOR  PIC  CXA,B,C 


Rank 

Number 

of 

Trans¬ 

actions 

Gross 
Numbe  r 
of 

Chains 

Net 

Number 

of 

Chains 

%  of  Gross 
Total  of 

CXA , B , C 
Chains 

Cum  %  of 
Gross  Total 
CXA ,  B ,  C 
Chains 

2 

63,267 

27 

58.7 

58.7 

3 

15,291 

139 

14.2 

72.9 

4 

13,051 

328 

12.1 

85.0 

1 

5,226 

3 

4.9 

89.9 

5 

4,575 

399 

4.2 

94.1 

6 

3,116 

386 

2.9 

97.0 

7 

1,776 

275 

1.6 

98.7 

8 

8 

1,092 

190 

1.0 

99.7 

9 

9 

201 

94 

0.2 

99.9 

10 

10 

53 

32 

99.9 

11 

11 

48 

26 

99.9 

12 

12 

13 

11 

99.9 

13 

7 

7 

99.9 

14 

14 

5 

5 

99.9 

15 

16 

2 

2 

99.9 

16 

15 

1 

1 

99.9 

17 

30 

1 

1 

99.9 

Total 

107,725 

1,926 

100.0 

Source:  DODSSR  Data  Collection;  Transition  Population 


Figure  1-92 
(5)  WXA/WXB  Chains 

Chains  for  WIMM  items  are  shown  in  Figure  1-93. 
About  5.5%  of  the  WIMM  chains  had  over  four  transactions;  and 
only  1%  had  six  or  more.  Clearly  WIMM  chains  are  less  complex 
than  CIMM  chains.  However,  about  22%  had  only  one  transaction 
indicating  that  there  was  a  large  percentage  of  advice  that  had 
not  been  received  even  though  at  least  four  months  had  elapsed 
since  the  request.  Since  most  of  the  WIMM  requests  are  for  NSNs, 
the  chains  should  be  simpler.  Of  the  22%  single  transaction 
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overall  this  compared  with  the  12.5%  single  transaction  for  NSNs, 
and  82.3%  single  transaction  for  part  numbered  W1MM  items.  It  is 
speculated  that  a  large  number  of  the  82.3%  were  replied  to  by 
letter  and  that  the  CXI  advice  card  was  not  forwarded. 


RANK  AND  FREQUENCY  DISTRIBUTION  OF 
NUMBER  OF  TRANSACTIONS /CHAIN  FOR  PIC  WXA,B 


Rank 

Number 
o  f 

Trans¬ 

actions 

Gross 

Number 

of 

Chains 

Net 

Number 

of 

Chains 

%  of  Gross 
Total  of 

WXA ,  B 
Chains 

Cum  %  of 
Gross  Total 
WXA ,  B 
Chains 

1 

2 

1,215 

15 

47.3 

47.3 

2 

1 

555 

2 

21.6 

68.9 

3 

3 

361 

29 

14.0 

82.9 

4 

* 

299 

41 

11 . 6 

94.5 

5 

5 

115 

34 

4 . 5 

99.0 

6 

6 

12 

11 

0.5 

99.5 

7 

7 

8 

7 

0.3 

99.8 

8 

8 

4 

4 

0.1 

99.9 

9 

10 

1 

1 

99.9 

10 

13 

1 

1 

100.0 

Total 

2,571 

145 

Source:  D0DS3R  Data  Collection;  Transition  Population 


Figure  1-93 

(6)  Multiple  Transaction  Chains.  The  transaction/ 
chain  frequency  distribution  indicated  that  over  20%  of  all  SSR 
chains  have  four  or  more  transactions.  If  everything  went  as 
expected,  one  would  expect  chains  to  be  completed  in  a  maximum  of 
three  transactions.  There  are  three  events  that  contribute  the 
most  to  causing  long  chains.  These  are  offers,  rejects  and  fol¬ 
lowups.  Offers  are  expected  and  normal  events  that  occur  approxi¬ 
mately  5%  of  the  time.  Rejects  and  followups  occur  when  the 
system  is  not  working  as  it  should.  Followups  or  rejects  occur 
in  a  large  number  of  the  chains  with  four  or  more  transactions; 
these  types  of  chains  were  further  analyzed  to  determine  their 
incidence  and  significance. 

(a)  Reject  Chains .  Figure  1-94  shows  that 
about  92%  of  the  chains  with  rejects  contained  only  one  reject 
per  chain.  There  were  7.3%  with  two  rejects  per  chain  and  only 
0.1%  with  three  or  more  rejects  per  chain.  This  was  rather  sur¬ 
prising  in  view  of  the  large  number  of  complaints  received  during 
the  course  of  our  research  that  requests  were  being  continually 
rejected  more  than  once  and  that  all  errors  should  be  detected 


and  rejected  in  one  pass.  Either  the  incidence  of  multiple  errors 
per  reject  are  lower  than  originally  anticipated  or  additional 
errors  are  being  edited  by  the  receiver  or  the  submitter  is  cor¬ 
recting  any  additional  errors  prior  to  resubmission.  An  eight 
percent  multiple  reject  rate  per  chain  is  still  considered  rather 
high . 

REJECTS  PER  REJECT  CHAIN  PATTERN 


Number 

Rejects 

Net 

Number 

Chains 

Cross 

Number 

Chains 

Percent 

Gross 

Chains 

Cumulative  % 
Gross 
Chains 

1 

432 

43,098 

92.0% 

92.0% 

2 

194 

3,424 

7.3 

99.3 

3 

64 

266 

0.6 

99.9 

4 

17 

34 

0.1 

100.0 

5 

3 

5 

0.0 

100.0 

6 

2 

2 

0.0 

100.0 

7 

1 

1 

0.0 

100.0 

8 

1 

1 

0.0 

100.0 

9 

1 

1 

0.0 

100.0 

10 

0 

0 

0.0 

100.0 

11 

1 

1 

0.0 

100.0 

Total 

716 

| 

100.0% 

Source:  DODSSR  Data  Collection,  Transition  Population 


Figure  1-94 

(b)  Followup  Chains.  Followups  per  chain  are 
shown  in  Figure  1-95.  Over  70%  of  chains  containing  a  follow¬ 
up,  have  only  one  followup  per  chain.  But,  this  means  that  al¬ 
most  30%  of  the  time  when  a  followup  is  made  there  will  be  two 
or  more  followups  made.  It  was  previously  shown  that  most  of 
the  followups  are  generated  by  the  Air  Force.  It  is  believed 
that  the  occurrence  of  multiple  followups  over  the  life  cycle  of 
an  SSR  is  caused  by  a  combination  of  circumstances.  The  Air 
Force  system  of  following  up  based  upon  the  date  of  generation  of 
the  request  as  opposed  to  the  date  of  transmission  causes  follow¬ 
ups  to  be  sent  too  soon  resulting  in  either  interim  or  No  Record 
advice  being  sent  by  the  IMM.  If  a  No  Record  condition  occurs, 
the  Air  Force  will  resubmit  another  SSR  for  the  same  item.  This 
can  result  in  a  series  of  followups  and  advice  occurring  over 
the  life  cycle  of  an  SSR.  The  Air  Force  system  permits  SSRs  to 
be  forwarded  with  the  same  PCC,  ISN,  with  and  without  a  new  DOR, 
even  though  a  type  change  code  is  not  used  to  show  a  change  trans¬ 
action.  The  same  ISN  may  be  user  for  the  same  or  a  different 
item  of  supply  on  the  same  or  different  dates  for  the  same  PCC. 
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Followups  may  be  sent  out  on  one  request,  advice  sent  out  or  re¬ 
ceived  on  the  Identical  or  similar  SSR.  The  advice  received  may 
be  recorded  on  the  correct  SSR  In  the  suspense  file  or  may  be 
applied  to  a  different  but  similar  item*  The  combination  of  when 
a  followup  is  sent  out,  when  it  is  received,  the  use  of  different 
media  for  transmitting  requests  and  advice  transactions,  and  the 
use  of  different  conventions  for  applying  control  data  to  the 
generation,  storage  and  retrieval  of  SSRs  in  suspense  files  con¬ 
tributes  to  the  incidence  of  multiple  followups  over  the  life 
cycle  of  an  SSR. 

FOLLOWUPS  PER  FOLLOWUP  CHAIN  PATTERN 


Net 

Number 

Chains 

Gross 

Number 

Chains 

Percent 

Gross 

Chains 

Cumulative  % 
Gross 
Chains 

i 

389 

14,548 

72.7% 

72.7% 

2 

245 

3,877 

19.4 

92.1 

3 

113 

1,572 

7.8 

99.9 

4 

14 

20 

0.1 

100.0 

5 

4 

4 

0.0 

100.0 

6 

1 

1 

0.0 

100.0 

Total 

766 

1 

100.0% 

Source:  DODSS&  Data  Collection;  Transition  Population 


Figure  1-95 

(c)  Summary*  Long  SSR  chains  are  caused  by  a 
combination  of  circumstances.  Rejects  and  followups  are  the 
principal  forces  causing  long  chains.  However,  these  two  events 
do  not  necessarily  occur  independently  of  each  other  or  of  othei 
events.  Both  rejects  and  followups  may  occur  in  the  same  chain 
along  with  other  events  such  as  offers.  The  timing  of  the  genera 
tion  of  transactions  coupled  with  the  use  of  different  media  for 
transmitting  different  types  of  transactions  and  the  use  of  dif¬ 
ferent  rules  for  the  application  of  control  data  in  the  genera¬ 
tion,  sequencing,  storage,  retrieval,  and  purging  of  records  com¬ 
pounds  the  problem.  Because  of  the  wide  variance  in  the  number 
of  different  types  and  subtypes  of  chain  patterns,  a  more  exten¬ 
sive  analysis  of  SSR  chains  and  classification  of  chain  patterns 
is  contained  in  the  network  analysis  below.  A  further  analysis 
of  the  use  of  different  rules  and  convention  as  relates  to  con¬ 
trol  data  is  contained  in  an  analysis  of  the  commonality  of  SSRs 
at  the  end  of  this  Chapter. 

6.  Network  Analysis.  Throughout  this  report  we  have  dis¬ 
cussed  SSR  processing  in  terms  of  a  system  containing  a  series 
of  processing  phases,  events,  steps,  and  tasks.  If  the  events  in 


127 


this  system  are  tied  together  through  a  communications  link  and 
times  are  added  for  the  completion  of  events,  the  system  can  be 
thought  of  as  a  network.  Through  an  analysis  of  this  network, 
measurements  of  time  to  complete  a  single  event,  transmit  the 
results  of  that  event  to  the  next  phase  or  event,  or  to  accomp¬ 
lish  an  entire  chain  of  action  can  be  recorded.  Relation  of 
events  to  each  other  and  within  a  chain  of  events  can  be  made. 
Also  different  types  of  chain  patterns  or  network  patterns  can  be 
compared  to  each  other.  Through  an  analysis  of  different  events 
and  their  time/effect  relationships,  it  is  possible  to  better 
understand  the  SSR  process  and  to  detect  and  correct  deficiencies 
in  the  system.  This  section  provides  an  analysis  of  the  time  to 
transmit  SSR  documents,  time  to  complete  single  events  and  the 
time  to  complete  SSR  networks  of  varying  types.  The  time  measure 
ments  can  then  be  compared  against  allowed  times  for  the  accomp¬ 
lishment  of  certain  events. 

a .  Performance  Evaluation 

Performance  evaluation  is  defined  by  the  Work  Measure 
ment  Standardization  Manual  (Appendix  D,  Reference  27)  as  a  cri¬ 
tical  and  objective  appraisal  of  performance  data  and  related 
information  to  obtain  an  accurate  picture  of  overall  status  of  a 
specific  area,  ascertain  exceptional  accomplishments,  identify 
shortfalls  and  their  causative  factors,  and  development  meaning¬ 
ful  recommendations.  During  headquarters  and  field  research,  the 
study  team  attempted  to  determine  if  there  was  an  existing  or 
planned  system  at  any  of  the  Components  to  evaluate  the  effective 
ness  of  the  SSR  system  in  terms  of  qualitative  or  quantitative 
measures  that  were  being  used  to  evaluate  the  level  of  perfor¬ 
mance  in  terms  of  some  standard,  set  of  criteria,  or  end  objec¬ 
tive.  The  study  team  could  find  no  management  performance  goals 
or  objectives  in  the  IMM  directives  or  manuals,  Component  direc¬ 
tives  or  use  in  actual  practice  at  operating  activities.  A  man¬ 
agement  performance  goal  or  objective  in  this  sense  is  one  that 
is  expressed  in  specific  qualitative  or  quantitative  terms  to  be 
attained  within  or  over  a  designated  period  of  time.  Performance 
goals / ob jec t i ves  are  viewed  as  achievement  targets  or  ideal  end 
levels  to  be  obtained.  An  example  of  such  an  objective  might  be 
achieving  an  SSR  reject  rate  of  less  than  5%  or  processing  95%  of 
all  SSRs  within  25  days. 

Since  we  could  not  find  any  performance  goals/objec¬ 
tives  it  was  logical  that  we  could  not  find  any  performance 
measurement  indexes,  performance  indicators  or  performance  rating 
scales.  In  order  to  measure  performance  against  a  goal  it  is 
logical  to  have  a  performance  standard  or  benchmark  to  which 
actual  performance  is  to  be  compared.  We  could  not  find  any 
standard  within  the  strict  definition  of  the  term;  however,  we 
discovered  that  the  IMM  Manual  did  contain  a  number  of  allowed 


times  tor  accomplishing  certain  actions  or  events  in  the  SSR  sys¬ 
tem.  These  times  are  spread  throughout  the  SSR  procedures  and 
are  not  concentrated  in  any  one  area  with  a  requirement  for  measur¬ 
ing  and  recording  the  accomplishment  of  events  with  respect  to 
allowed  times,  or  to  compare  these  accomplishments  against  any 
predetermined  goals,  objectives  or  standards.  The  study  team 
extracted  and  combined  all  the  times  for  accomplishing  SSR  related 
events  into  the  table  shown  in  Figure  1-96. 

Start  and  stop  points  for  measuring  times  were  deter¬ 
mined  and  included  in  the  table.  The  IMM  Manual  does  not  contain 
allowed  times  for  transmission  of  SSR  request  or  advice  transac¬ 
tions.  Inferred  times  were  statistically  computed  based  upon  the 
ten-day  differential  between  the  25  days  allowed  time  for  initial 
advice  and  the  35-day  followup  time  for  initial  advice.  The  ten 
day  differential  was  allocated  evenly  to  transmission  time  for 
the  request  and  transmission  time  for  the  advice  on  the  request. 

There  also  was  no  allowed  time  for  the  resubmission 
of  a  request  transaction  when  the  initial  transaction  is  rejected. 
The  study  team  had  no  basis  for  generating  an  inferred  time  for 
this  event.  However,  an  attempt  was  made  to  measure  the  time  be¬ 
tween  the  rejection  of  a  request  and  the  resubmission  event.  The 
results  of  this  measurement  is  provided  later  in  this  section. 

The  allowed  time  for  the  condition  involving  sub¬ 
mitting  a  funded  requisition  occurs  when  the  IMM  sends  an  advice 
indicating  that  supply  support  is  accepted,  but  that  the  item 
requested  will  be  supported  on  a  centrally  procured,  not  stocked 
(AAC  J)  basis.  Since  the  requisitioning  process  is  outside  the 
scope  of  the  DODSSR  Study,  the  study  team  had  no  way  of  measuring 
this  condition.  However,  one  comment  is  offered.  The  procedures 
specify  that  the  funded  requisition  is  to  be  submitted  180  days 
prior  to  the  required  date.  Thi6  appears  to  be  inconsistent  with 
the  requirement  for  stocked  items  in  that  the  SSR  is  required  to 
be  submitted  no  more  than  a  leadtime  away  from  the  required  date. 

If  the  leadtime  is  less  than  180  days  the  requirement  for  stocked 
items  is  less  stringent  than  for  not  stocked  items.  Also  a  cer¬ 
tain  amount  of  time  is  lost  to  the  SICC,  since  he  must  wait  until 
receiving  the  AAC  J  advice  prior  to  sending  the  requisition.  The 
SICC  has  no  way  of  knowing  in  advance  that  the  IMM  is  going  to 
support  the  item  through  procurement  rather  than  stocking  the 
item.  This  is  even  more  significant  for  requests  for  part  num¬ 
bered  items  since  the  SICC  must  wait  for  the  NSN  notification 
before  submitting  a  requisition  for  the  item. 

The  study  team  could  not  measure  the  number  of  SSR 
changes  that  occurred  within  two  years  after  the  initial  request, 
since  the  data  collection  was  only  for  an  8-month  timeframe.  The 
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SSR  EVENT  COMPLETION  TIMEFRAMES 


Event 

Days 

Allowed 

Time 

Days 

In¬ 

ferred 

Time 

Start 

Date 

Stop 

Date 

Request  Transmission 

5 

Submission 

Receipt 

Advice  Transmission 

5 

Submission 

Receipt 

Initial  Advice 

25 

Request 

Receipt 

Advice 

Submission 

Delayed  Advice 

15 

Pending 

Advice 

Initial 

Advice 

NSN  Advice 

NSN  Date 
60 

Request / 

Reply 

Receipt 

NSN  Need 

Date/ 

Advice 

Reply  to  Offer 

60 

Offer 

Date 

Reply 

Receipt 

Initial  Followup 

35 

Request 

Submission 

Advice 

Receipt 

NSN  Followup 

70 

Request/ 

Reply 

Submission 

Advice 

Receipt 

Response  to  Followup 

15 

Followup 

Receipt 

Advice 

Submission 

Request  Cancellation 

15 

Advice 

Receipt 

Cancellation 

Submission 

Request  Resubmlsslon 

? 

? 

Advice 
Reques  t 

Request 

Resubmission 

Funded  Requisition 

180 

Requisition 

Submission 

Date 

Required 

SSR  Suspense  Purge 

120 

Final 

Advice 

Purge 

Date 

Request  Changes 

730 

Original 

Request 

Date 

Change 

Date 

Source:  SSR  Procedures 

Figure 

1-96 

\  - 
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120-day  purge  time  frame  for  SSR  suspense  records  seems  to  be 
inconsistent  with  the  2-year  timeframe  for  submitting  changes. 

If  a  change  occurs  six  months  after  the  initial  request  for  which 
a  final  advice  has  been  received,  the  initial  request  will  not  be  \ 
in  the  suspense  file,  since  it  will  have  been  purged  after  four 
months  . 


The  SSR  transaction  formats  were  searched  for  any 
date  or  time  indicator  that  could  be  used  to  provide  a  basis  for 
measuring  the  actual  time  for  accomplishing  events  in  order  to 
permit  a  comparison  with  allowed  or  inferred  times.  These  indi¬ 
cators  are  shown  in  Figure  1-97. 

The  common  submit  ter /receiver  data  are  those  that  are 
normally  entered  in  SSR  transactions  in  the  card  columns  shown 
for  the  program  data  card,  line  items  cards,  conditions  1,  2,  3 
and  advice  cards.  The  submitter  and  receiver  data  is  data  that 
was  added  to  the  record  as  a  result  of  the  data  collection.  The 
date  the  submitter  sent  the  SSR  to  the  IMM  (receiver)  was  placed 
in  positions  60-63  of  the  record  sent  to  the  data  collection  and 
recorded  in  the  same  positions  in  the  combined  submitter /receiver 
record  in  the  DODSSR  data  base.  The  date  the  receiver  received 
the  actual  SSR  was  entered  into  positions  60-63  of  the  copy  of 
the  SSR  transaction  sent  to  the  data  collection,  but  recorded  in 
positions  96-99  of  the  Combined  Submitter/Receiver  record  in  the 
DODSSR  data  base.  The  AUTODIN  dates  when  the  transactions  were 
sent  to  DODSSR  by  the  submitter  and  receivers  were  extracted  from 
the  AUTODIN  header  cards  and  included  in  the  data  base.  Also, 
the  study  team  recorded  the  date  the  cards  were  received  by  the 
DODSSR  data  base  management  system  from  the  AUTODIN  system. 


The  DODSSR  study  team  developed  a  series  of  Perfor¬ 
mance  Evaluation  Computer  Programs  to  analyze  the  performance  of 
the  SSR  system.  The  date/time  indicators  shown  in  Figure  1-97 
were  used  in  conjunction  with  the  timeframes  shown  in  Figure  1-96 
and  applied  to  events  occurring  in  various  transaction  chain  pat-  I 

terns  as  shown  in  Figure  1-98.  This  performance  evaluation  system 
permitted  an  analysis  of  transmission  times,  single  event  times  i 

and  life  cycle  analysis  of  an  entire  SSR  transaction  chain  through 
the  development  of  SSR  networks  as  shown  in  Figure  1-98. 


The  large  circles  represent  transactions  or  events  in 
the  SSR  system.  The  type  of  event  is  represented  by  a  3-digit 
computer  code  the  first  digit  of  which  is  shown  in  the  circles  to 
signify  the  major  event  type  as  indicated  in  Figure  1-86.  The 
numbers  between  the  circles  represent  the  time  to  accomplish  the 
event  on  the  right  after  the  event  on  the  left  has  occurred.  By 
looking  at  different  networks,  computing  the  actual  times  for  an 
event  using  the  dates  in  the  transactions,  and  summing  up  the 
computed  times  for  all  events  in  a  network;  the  total  life  cycle 
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DATES  AND  TIMES  ENTERED  ON  DODSSR  COMBINED  RECORD 


Character  Position  | 

LISSR  Condition 

Required  Dates/Times 

PDSSR 

1 

2 

3 

LI  AC 

COMMON  SUBMITTER/RECEIVER  DATA 

Date  Request 

49-52 

49-52 

49-52 

49-52 

49-52 

Date  of  Advice 

53-56 

Date  Support  Will  Be  Provided 

77-80 

Y  X  Date 

77-80 

Date  Repair  Parts  Required 

25-28 

Date  Tech  Data  to  be  Supplied 

69-72 

Date  NSNs  Required 

21-24 

Calendar  Year 

53 

Calendar  Year  Quarter 

54 

No.  of  Months  in  Delivery  Cycle 

55-56 

Production  Leadtime 

72-73 

SUBMITTER  DATA 

Date  Official  SSR  Sent 

60-63 

60-63 

60-63 

60-63 

60-63 

AUTODIN  Date  SSR  Copy  Sent  to 
DODSSR  Data  Base 

81-84 

81-84 

81-84 

81-84 

81-84 

AUTODIN  Date  SSR  Copy  Received 
by  DODSSR  Data  Base 

85-88 

85-88 

85-88 

85-88 

85-88 

RECEIVER  DATA 

Date  Official  SSR  Received 

96-99 

96-99 

96-99 

96-99 

96-99 

AUTODIN  Date  SSR  Copy  Sent  to 
DODSSR  Data  Base 

100-103 

100-103 

100-103 

100-103 

100-103 

AUTODIN  Date  SSR  Copy  Received 
by  DODSSR  Data  Base 

104-407 

104-107 

104-107 

104-107 

104-107 

Source:  SSR  Procedures 


Figure  1-97 
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Figure  1-98 


support  time  can  be  determined.  The  performance  of  the  system  can 
then  be  determined  by  comparing  the  actual  times  with  the  allowed 
times*  In  addition  to  total  life  cycle  times,  times  for  individ¬ 
ual  event  pairs  can  be  computed  as  well  as  the  time  to  transmit 
transactions  from  one  point  to  the  other  via  different  types  of 
communications  media. 

The  25  between  the  Request  (0)  event  and  the  Accept 
(1)  represents  the  25-day  timeframe  allowed  for  initial  advice  by 
the  IMM  after  receipt  of  a  request  transaction.  Sixty  days  are 
allowed  from  the  time  of  the  receipt  of  a  part  numbered  transac¬ 
tion  until  the  forwarding  of  NSN  advice.  If  25  days  are  used  to 
give  the  initial  advice,  then  60  less  25  days  or  35  days  are 
allowed  after  the  Accept  (1)  event  to  accomplish  the  Accept  NSN 
(1)  event.  The  total  allowed  time  is  60  days.  The  time  for  the 
first  accept  event  is  25  days  and  the  time  for  the  NSN  event  is 
60  minus  the  time  for  the  initial  accept.  The  actual  time  can  be 
computed  and  compared  with  the  allowed  times  for  single  events  or 
life  cycle  chains  of  events.  Transmission  times  are  not  shown 
here  since  they  are  not  directly  provided  for  in  allowed  times  in 
the  IMM  Manual.  However,  they  are  very  important  because  extended 
transmission  times  can  delay  the  occurrence  of  an  event  in  the 
eyes  of  a  transaction  submitter  and  result  in  a  followup  which 
might  not  have  been  necessary.  Because  of  the  Importance  of  all 
these  times,  the  study  team  computed  times  for  transmission, 
single  events  and  life  cycle  chains  independently  and  considered 
all  three  in  the  performance  evaluation. 

b .  Submission/Transmission  Times 


Submission/transmission  times  are  the  times  it  takes 
from  the  generation  of  an  SSR  transaction  by  the  submitter  until 
it  is  received  by  the  receiver.  There  are  a  number  of  subevents 
Included  in  the  total  time  to  transfer  an  SSR  from  the  SICC  to 
the  IMM  or  to  transfer  advice  from  the  IMM  back  to  the  SICC. 

These  times  will  vary  depending  upon  the  degree  of  automation  of 
the  sending  and  receiving  activities,  local  procedures  and  the 
media  (mall  or  AUTODIN)  used  to  convey  the  transaction  from  one 
point  to  another.  The  DODSSR  Data  Collection  was  used  to  compute 
certain  subevents  related  to  the  total  time  to  transfer  an  SSR 
transaction  from  the  generating  activity  to  the  receiving  activ¬ 
ity: 


Internal  Processing  Time  -  This  time  was  computed  by  subtract¬ 
ing  the  Date  of  Request  (DOR)  from  the  minimum  of  the  official 
and  AUTODIN  submit  dates.  This  approach  was  used  to  attribute 
the  smallest  time  possible  to  the  submitter  based  upon  the  time 
the  transaction  was  ready  to  be  transmitted  to  the  receiver.  The 
assignment  of  DORs  varies  by  Component  as  was  described  in  Volume 
II.  Also  the  procedures  used  to  batch  transactions  may  vary  by 


Component  or  even  by  activity.  This  time  provides  an  estimate  of 
the  internal  time  required  at  the  submitting  activity  from  the 
point  when  the  SSR  transaction  was  generated  until  the  transaction 
was  ready  to  be  submitted.  In  the  case  of  advice  transactions, 
the  Date  of  Advice  (DOA)  was  used  in  place  of  the  DOR. 

Net  Transfer  Time  -  This  time  was  computed  by  subtracting  the 
minimum  of  the  official  and  AUTODIN  dates  submitted  from  the 
minimum  of  the  official  and  AUTODIN  dates  received.  The  intent 
here  is  to  remove  the  influence  of  the  varying  Component  proce¬ 
dures  used  to  construct  the  DOR,  and  to  show  the  time  from  the 
earliest  point  when  the  transaction  could  be  submitted  until  the 
earliest  time  it  could  be  received. 

AUTODIN  Transmit  Time  -  This  is  the  time  to  physically  trans¬ 
port  a  transaction  from  one  activity  to  another.  These  times 
were  computed  based  upon  the  submission  of  the  "copy  transaction" 
to  the  DODSSR  Data  Base  and  is  shown  for  comparison  purposes. 

This  time  is  not  included  in  those  transactions  that  are  mailed. 
However,  it  is  representative  for  those  transactions  that  are 
forwarded  over  AUTODIN.  It  is  computed  by  subtracting  the  AUTODIN 
date  received  from  the  AUTODIN  date  submitted. 

Gross  Transfer  Time  -  This  is  the  time  to  transfer  an  SSR 
transaction  from  the  date  of  request  until  received  by  the 
receiving  activity.  It  is  computed  by  subtracting  the  DOR  for 
requests,  or  the  DOA  for  advice,  from  the  minimum  of  the  official 
and  AUTODIN  receipt  dates.  The  intent  is  to  show  the  influence 
of  the  DOR  by  comparing  this  time  with  the  internal  and  net  times. 


The  SSR  Procedures  prescribed  at  the  time  of  the 
study  for  the  use  of  mail  to  transport  request  transactions  from 
the  SICC  to  the  IMM.  The  DODSSR  Study  Team  established  a  test  to 
determine  the  feasibility  of  using  AUTODIN  in  place  of  mail.  The 
results  of  this  test  are  discussed  in  Chapter  II.  (Request  trans¬ 
actions  were  forwarded  by  mail,  except  for  this  test  period  for 
the  test  activities.)  Historically  SSRs  have  been  mailed  because 
of  the  use  of  packaging  procedures  to  process  SSRs  and  because  of 
the  need  to  transmit  technical  data  for  some  items. 

Figure  1-99  shows  the  times  to  transfer  request 
transactions  from  a  SICC  to  an  IMM  for  CIMM  items. 


The  average  net  time  to  transfer  an  SSR  was 
about  13  days.  Fifty  percent  of  the  time  it  took  15  days;  how¬ 
ever,  it  could  take  as  much  as  a  month  or  more  to  transfer  an 
SSR  from  one  activity  to  another.  The  longer  timeframes  are 
attributable  to  the  time  required  at  the  submitting  activity  to 


aatch  SSRs  with  drawings  and  to  pack  SSRs  and  related  technical 
data  In  boxes  for  mailing  to  the  IMM.  Our  research  Indicated 
that  SSRs  for  NSN  and  part  numbered  Items  were  generally  packed 
and  mailed  together  even  thou  gh  NSN  items  do  not  require  tech¬ 
nical  data*  However,  in  the  Marine  Corps  NSN,  PSCN  and  part 
number  items  are  processed,  batched  and  mailed  separately* 

SICC  SSR  SUBMISSION/TRANSMISSION  TIMES  FOR  CIMM  ITEMS 

(Number  of  Days) 


Times 

Mean 

Standard 

Deviation 

lOX-ile 

50Z-1 le 

90%-ile 

Internal 

-9.1 

15 

-30 

0 

0 

Net 

12.7 

30 

5 

15 

31 

AUTODIN 

1.0 

7 

0 

1 

3 

Gross 

3.2 

31 

-21 

11 

22 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-99 

Note  that  the  gross  time  is  less  than  the  net  time. 
Normally  thl"  would  appear  odd,  but  this  is  explainable  by  look¬ 
ing  at  the  mean  time  for  internal  processing.  The  date  of  request 
would  normally  be  expected  to  be  the  date  when  the  SSR  was  gener¬ 
ated.  This  is  the  case  in  the  Air  Force  where  the  SSR  is  generated 
by  the  computer.  When  the  SSR  is  manually  generated,  or  for  the 
automated  systems  in  the  Army  and  the  Navy;  the  DOR  is  created  by 
adding  a  fixed  number  of  days  to  the  date  the  computer  generates 
the  transaction  to  allow  for  internal  processing  time  to  match  up 
SSRs  and  drawings  and  to  pack  for  mailing.  When  the  SSRs  are 
actually  submitted  prior  to  the  parameter  used  to  construct  the 
DOR,  a  negative  time  is  generated  for  this  event.  This  negative 
time  also  affects  the  gross  time  to  transfer  an  SSR,  making  it 
appear  that  it  takes  less  time  than  actually  occurs. 

Followups  are  supposed  to  be  generated  based 
upon  the  date  submitted.  If  the  DOR  is  used  this  can  mean  that 
the  followup  is  generated  either  early  or  late,  depending  upon 
how  the  DOR  is  constructed.  The  date  submitted  was  generated  for 
the  DODSSR  data  collection  and  is  not  normally  available  to  the 
SICC  to  be  used  for  followup  purposes.  Therefore,  the  DOR  is 
generally  the  starting  point  for  determining  when  a  followup  will 
be  sent.  The  sum  of  the  net  and  internal  times  do  not  precisely 
equal  the  gross  times  though  they  are  approximately  equal.  This 
is  due  to  the  fact  that  the  number  of  observations  are  not  the 
same  for  each  time  computation  due  to  the  default  routine  used  to 
utilize  the  most  appropriate  date  field  containing  valid  data. 
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The  AUTODIN  time  is  shown  for  comparison  pur¬ 
poses.  Except  for  the  AUTODIN  test  described  in  Chapter  II, 
request  transactions  are  mailed  rather  than  sent  over  AUTODIN. 

The  AUTODIN  time  represents  an  approximation  of  the  net  time  if 
the  sending  and  receiving  activities  were  both  automated  and 
sending  and  receiving  transactions  over  AUTODIN. 

Figure  1-100  provides  statistics  on  WIMM  requests 
The  trend  is  the  same,  only  the  numbers  are  different.  The  net 
times  are  similar,  but  it  appears  that  the  DOR  is  slightly  less 
padded  for  WIMM  items  than  for  CIMM  items. 

SICC  SSR  SUBMISSION/TRANSMISSION  TIMES  FOR  WIMM  ITEMS 

(Number  of  Days) 


Times 

Mean 

S  tandard 
Deviation 

lOZ-ile 

50%-ile 

90Z-ile 

Internal 

-4.1 

8 

-12 

-5 

3 

Net 

14.4 

11 

6 

12 

26 

AUTODIN 

0.7 

1 

0 

1 

2 

Gross 

9.3 

13 

-4 

7 

26 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-100 

Since  the  system  times  were  similar  for  CIMM  and 
WIMM  It  was  decided  to  break  the  CIMM  times  down  by  Service  to 
see  If  there  was  any  significant  difference.  The  number  of  obser¬ 
vations  were  rather  small  on  a  Component  basis  for  WIMM  items. 
Figure  1-101  provides  statistics  by  Component  for  CIMM  requests. 

SICC  SSR  SUBMISSION/TRANSMISSION  TIMES  FOR  CIMM  ITEMS 
(Average  Number  Days) 


Component 

Internal 

f  Net  "1 

AUTODIN 

Gross 

Army 

2.1 

1.4 

19.0 

Navy 

-25.9 

1.7 

-8.2 

Air  Force 

0 

7.9 

0.5 

8.0 

Marine  Corps 

-10.1 

12.0 

1.2 

2.2 

Total 

-1.2 

12.7 

1.3 

msm 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-101 
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As  you  can  see,  there  is  a  wide  variation  for 
all  times  except  for  AUTODIN  times.  Although  the  Army  shows  a 

2.1  average  for  internal  time,  there  is  a  standard  deviation  of 

9.2  indicating  that  on  an  activity  basis  and  for  individual  trans¬ 
actions  the  internal  time  can  be  negative  or  range  as  high  as  14 
days  at  the  90th  percentile.  Net  times  for  Army  can  range  from 
two  days  at  the  10th  percentile  to  43  days  at  the  90th  percentile. 
Gross  times  range  from  6  to  43  days,  with  negative  times  possible 
on  an  activity  and  individual  transaction  basis. 

The  negative  internal  and  gross  times  for  Navy 
shows  that  if  times  were  measured  using  the  DOR  as  a  starting 
point,  the  SSR  would  theoretically  be  received  before  it  was  sent. 
This  is  due  to  the  internal  processing  time  that  is  added  to  the 
date  the  SSR  is  generated  to  create  the  DOR.  The  internal  pro¬ 
cessing  time  at  Navy  is  consistently  less  than  or  equal  to  zero. 
This  is  not  a  true  situation,  based  upon  our  systems  and  field 
research.  But  the  DORs  are  representive  of  what  is  actually 
being  put  into  SSRs  which  are  introduced  into  the  system.  The 
more  appropriate  net  time  indicates  that  Navy  SSRs  take  anywhere 
from  two  to  four  weeks  transfer  time. 

The  Air  Force  DOR  is  equal  to  the  date  the  SSR 
was  actually  generated  by  the  computer.  The  Air  Force  indicated 
via  the  official  submit  date  and  their  AUTODIN  submission  dates 
that  the  transactions  were  submitted  on  the  same  day.  The  copy 
transaction  was  sent  to  DODSSR  on  that  day,  but  field  research 
indicates  to  us  that  the  SSR  actually  was  mailed  later.  The 
actual  internal  processing  time  can  not  be  determined  from  the 
data  collection.  Actually  it  is  taking  anywhere  from  one  to  four 
weeks  net  time  to  communicate  an  SSR  from  fn  Air  Force  activity 
to  an  IMM. 

The  times  for  Marine  Corps  indicates  that  con¬ 
struction  of  a  DOR  also  makes  this  data  element  not  useful  for 
calculation  of  transfer  time  for  the  Marine  Corps.  Actual  trans¬ 
fer  time  may  take  up  to  three  to  four  weeks. 

The  leadtimes  for  communicating  request  trans¬ 
actions  from  a  SICC  to  an  IMM  are  taking  too  long  due  to  a  com¬ 
bination  of  internal  processing  time  on  both  the  sending  and  re¬ 
ceiving  ends,  and  due  to  the  time  it  takes  to  move  traffic  through 
the  packaging  and  mailing  process  on  a  manual  basis.  The  DODSSR 
Study  Team  conducted  a  test  to  see  if  this  process  could  be 
speeded  up.  The  results  of  that  test  are  contained  in  Chapter  II. 

(2 )  CXI  Advice  Transactions 

Transfer  times  for  communicating  advice  from  an 
IMM  to  a  SICC  are  shown  in  Figure  1-102. 
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IMM  CXI  ADVICE  SUBMISSION/TRANSMISSION  TIMES 
(Number  of  Days) 


Time  s 

Mean 

Standard 

Deviation 

10%-ile 

50%-ile 

90%-ile 

1— 

0.3 

12 

0 

1 

2 

3 . 7 

14 

0 

1 

6 

0 . 6 

3 

0 

1 

2 

B  ' ; 

3 . 7 

7 

0 

2 

7 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-102 

Times  shown  are  the  totals  for  all  activities 
and  Components.  The  internal  time  from  date  of  advice  to  sub¬ 
mission  is  low  because  advice  is  generally  provided  from  auto¬ 
mated  suspense  files.  These  statistics  are  dominated  by  the 
Defense  Logistics  Agency  due  to  the  volume  of  transactions  sent 
by  DLA.  The  internal  time  for  WIMM  advice  for  manual  activities 
can  run  rather  high.  The  average  time  for  Army  activities  varied 
from  1  to  15  days.  Navy  from  an  average  of  25  to  37  days  with  the 
Marines  experiencing  an  average  of  one  week. 

The  net  average  total  time  was  3.7  days  with  a 
range  of  zero  to  six  days.  The  DLA  net  and  gross  times  approxi¬ 
mate  the  system  total.  Means  for  the  Service  Components  with 
manual  systems  ranged  from  one  to  three  weeks  when  the  advice  was 
mailed.  Even  where  the  internal  time  was  low  for  WIMM,  the  use 
of  mail  severely  lengthened  the  time  to  receive  the  advice.  The 
SSR  Procedures  do  permit  the  use  of  AUTODIN  for  advice  transac¬ 
tions.  Clearly  where  advice  is  automated  from  generation  through 
communications  transmission  there  is  a  significant  savings  in 
submission/transmission  time. 

( 3 )  Reply  to  Offer  Transactions 


Transfer  times  for  communicating  a  SICC  reply  to 
an  IMM  offer  are  shown  in  Figure  1-103. 

The  SSR  procedures  permit  the  use  of  AUTODIN  to 
transport  LIACs.  At  the  time  the  reply  transaction  is  created, 
the  only  action  remaining  for  the  sender  is  to  submit  the  trans¬ 
action  to  the  IMM.  All  the  actions  required  to  review  the  offer 
and  to  make  a  decision  to  accept  or  reject  the  offer  have  been 
completed  at  the  time  the  reply  transaction  is  created.  Transfer 
events  are  common  between  requests  and  replies  once  the  transac¬ 
tions  are  created,  with  the  exception  that  requests  are  matched  up 
with  technical  data  prior  to  forwarding  and  must  be  mailed  while 
replies  may  be  forwarded  over  AUTODIN. 
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SICC  CX2  REPLY  SUBMISSION/TRANSMISSION  TIMES 
(Number  of  Days) 


SICC 

Component 

Times 

f 

1 

Mean 

Standard 

Devia¬ 

tion 

IB 

50Z- 

ile 

90Z- 

ile 

Na  vy 

Interna  1 

3.6 

2 

2 

2 

Net 

21.6 

3 

21 

21 

AUTODIN 

0.7 

1 

0 

o 

Gross 

24.1 

5 

23 

23 

30 

Air 

Interna  1 

0.0 

0 

0 

0 

0 

Force 

Net 

2.1 

3 

0 

2 

3 

AUTODIN 

0.1 

1 

0 

0 

1 

Gross 

2.1 

3 

0 

2 

3 

Total 

Internal 

0.8 

4 

0 

0 

2 

Net 

3.3 

5 

0 

2 

4 

AUTODIN 

0.2 

1 

0 

0 

1 

Gross 

3.4 

12 

0 

2 

4 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-103 

The  statistics  for  replies  are  heavily  dominated 
by  the  Air  Force  because  of  the  volume  of  their  traffic.  The 
other  Services  did  not  have  enough  traffic  during  the  steady  state 
period  to  influence  the  system  totals  or  to  be  shown  separately 
so  the  population  for  the  entire  data  collection  period  was  used. 
Once  the  reply  transaction  is  created  by  the  computer,  the  Air 
Force  forwards  the  reply  by  AUTODIN.  DLA  is  the  dominant  receiver 
of  reply  transactions  and  provides  for  direct  transfer  of  the 
reply  from  the  AUTODIN  system  to  their  computer  system.  Internal 
processing  time  as  shown  in  the  table  is  therefore  held  to  a 
minimum  on  both  the  sending  and  receiving  sides. 

Even  in  the  main  population  only  the  Navy  and 
the  Air  Force  had  enough  transactions  to  show  separately.  Be¬ 
cause  of  their  volumes  the  Air  Force  statistics  approach  the 
system  statistics.  But,  notice  the  Navy;  about  three  weeks  are 
required  to  transmit  the  reply  to  the  IMM.  The  differences  in 
the  net  times  for  the  Navy  and  Air  Force  are  attributed  to  the 
time  required  by  Navy  to  prepare  the  reply  for  mailing  and  the 
mall  time. 


It  would  appear  from  the  statistics  shown  in 
this  table  in  comparison  with  the  transfer  times  for  requests 
that  tasks  related  to  the  transfer  of  the  transaction  should  be 
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automated  once  the  reply  decision  has  been  made.  Reducing  the 
transfer  time  would  tend  to  reduce  the  time  to  reply  to  offers 
and,  in  turn,  reduce  the  number  of  support  rejects  (ATC  08)  that 
occur  when  a  S1CC  has  not  replied  to  an  offer  within  60  days. 

(4)  CX3  Followups 

Followup  transactions  are  sent  by  a  SICC  to  an 
IMM  when  the  SICC  has  not  received  advice  from  the  IMM  on  a  pre¬ 
viously  submitted  request.  Figure  1-104  displays  statistical 
data  on  followups. 

SICC  CX3  FOLLOWUP  SUBMISSION/TRANSMISSION  TIMES 
(Number  of  Days) 


SICC 

Component 

Times 

Mean 

Standard 

Devia¬ 

tion 

10Z- 

ile 

50%- 

ile 

90X- 

lle 

Navy 

Internal 

7.8 

2 

3 

9 

9 

Net 

15.1 

3 

14 

14 

14 

AUTODIN 

6.0 

13 

1 

2 

3 

Gross 

16.2 

5 

6 

17 

17 

Air 

Interna  1 

0.0 

0 

0 

0 

0 

Force 

Net 

0.9 

1 

0 

1 

2 

AUTODIN 

0.9 

1 

0 

1 

3 

Gross 

1.1 

2 

0 

1 

2 

Total 

Interna  1 

2.4 

4 

0 

0 

9 

Net 

1.6 

4 

0 

1 

2 

AUTODIN 

0.9 

1 

0 

1 

2 

Gross 

2.1 

6 

0 

1 

3 

Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-104 

Once  again  the  Air  Force  is  the  dominating  Com¬ 
ponent  for  followups  as  well  as  replies.  However,  the  Navy  also 
had  significant  volume  for  followups.  The  same  type  of  picture 
is  presented  for  followups  as  for  replies.  The  Air  Force  is 
automated  with  followups  generated  by  the  computer  and  routed  to 
AUTODIN  for  transmission.  The  two  Navy  ICPs  were  in  different 
stages  of  implementation  of  their  automated  system  during  the 
time  the  data  was  collected.  The  longer  times  for  Navy  are  at¬ 
tributed  to  a  combination  of  manual  processing  and  mailing  time 
during  the  period  of  time  the  automated  system  had  not  been  im¬ 
plemented.  Even  when  the  followup  is  generated  on  an  automated 
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basis.  If  Che  transactions  are  then  output  for  manual  batching 
prior  to  forwarding  over  AUTODIN,  the  transfer  times  will  be 
longer  than  if  a  system  similar  to  the  Air  Force  is  used  where 
the  transactions  are  forwarded  from  the  computer  system  generat¬ 
ing  the  followup  to  the  AUTODIN  system. 

(5)  CX4  Responses  to  Followups 

An  IMM  is  required  to  repsond  to  a  followup  with 
in  IS  days  of  the  receipt  of  the  followup.  Figure  1-105  shows  the 
transfer  times  for  responses. 

IMM  CX4  RESPONSE  SUBMISSION/TRANSMISSION  TIMES 
(Number  of  Days) 


Source:  DODSSR  Data  Collection;  Steady  State  Population 


Figure  1-105 

The  times  are  almost  totally  dominated  by  DLA, 
due  to  the  volume  of  requests,  followups  and  responses  processed 
by  DLA.  The  volumes  for  other  Components  are  too  small  to  por¬ 
tray  or  even  to  speak  of.  Responses  are  generated  by  DLA  from 
the  SSR  suspense  file  on  an  automated  basis.  Once  the  response 
is  created  by  the  computer,  the  response  transaction  is  routed  to 
the  submitting  activity  via  the  AUTODIN  communications  system. 
Even  though  the  volumes  for  WIMM  IMMs  is  too  small  to  statisti¬ 
cally  portray,  it  appears  except  for  Air  Force,  that  those  few 
that  are  sent  are  handled  on  a  manual  basis  and  mailed,  thus 
Incurring  processing  time  associated  with  manual  processing  and 
mall  time. 

c.  Individual  Event  Times.  The  SSR  transaction  chains 
were  analyzed  to  determine  the  amount  of  time  required  to  com¬ 
plete  the  different  types  of  events.  In  order  to  measure  time 
for  Individual  events  it  was  necessary  to  search  the  chains  for 
pairs  of  transactions  that  were  related  and  to  measure  the  time 
between  the  occurrence  of  the  transaction  pairs.  Except  for  the 
request  transaction  that  initializes  the  chain,  subsequent  events 
or  transactions  are  caused  by  or  related  to  a  preceding  transac¬ 
tion.  These  transaction  pairs  were  Identified  and  the  time  to 
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complete  an  event  was  determined  by  subtracting  the  date  the  pre¬ 
ceding  transaction  was  completed  from  the  date  of  completion  of 
the  subsequent  related  transaction.  Transactions  had  to  be  con¬ 
tiguous  in  the  chain  to  be  considered.  In  other  words  if  an 
intervening  event  occurred  between  two  related  transactions  t  the 
individual  event  time  was  not  computed  because  the  related  trans¬ 
actions  did  not  occur  next  to  each  other  in  time.  Times  for 
transactions  with  intervening  events  were  considered  under  the 
life  cycle  network  analysis  in  subsection  C.6.d.  below.  Separate 
computer  reports  were  generated  for  each  of  the  individual  event 
time  types  and  are  discussed  in  this  section. 

( 1 )  Date  Repair  Parts  Required  (DRPR)  Need  Time 

The  DRPR  is  included  in  the  program  data  record 
by  the  submitter  to  indicate  when  supply  support  is  required. 

The  date  the  program  data  card  was  received  by  the  IMM  was  sub¬ 
tracted  from  the  DRPR  to  determine  the  amount  of  time  available 
to  the  IMM  to  provide  supply  support  for  the  items  in  an  SSR 
package  . 


Figure  1-106  shows  the  times  by  submitting  activ¬ 
ity  and  Component.  The  average  amount  of  time  allotted  to  the 
IMM  to  provide  supply  support  was  123  days.  There  was  quite  a 
large  variance  from  the  average  by  activity  and  by  Component. 
During  our  advice  analysis  we  noted  that  the  YX  advice  indicating 
a  new  support  date  was  generated  using  the  DRPR  and  the  produc¬ 
tion  leadtime  for  the  individual  item  being  requested.  The  YX 
advice  varied  considerably  by  submitting  activity  and  Component 
which  is  consistent  with  the  variance  in  DRPRs  shown  here. 

In  order  to  better  relate  DRPR  Need  Time  with  YX 
advice  we  generated  times  by  IMM  as  shown  in  Figure  1-107. 

As  explained  in  our  discussion  of  YX  advice,  DLA 
is  the  only  Component  that  consistently  considers  the  DRPR  in 
support  determinations.  DLA  also  has  the  most  volume  and  signif¬ 
icantly  influences  the  system  statistics.  There  is  a  consider¬ 
able  variance  in  IMM  activity  and  Component  times.  This  is  at¬ 
tributable  in  part  to  the  variances  in  production  leadtimes  by 
commodity.  But  in  order  to  determine  the  ability  of  the  IMMs  to 
meet  the  requested  timeframes,  it  was  necessary  to  determine  the 
reasonableness  of  the  DRPR  times. 
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PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
DRPR  NEED  TIME 


PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
DR PR  NEED  tlME 


Number  of  Daya 


I  MM 

Number 

Obser¬ 

vations 

Mean 

Std 

Devia¬ 

tion 

10Z- 

ile 

50Z- 

ile 

90Z- 

ile 

ARRCOM 

50 

128.5 

126 

0 

mm 

246 

CERCOM 

138 

143.3 

102 

27 

246 

MIRCOM 

70 

130.3 

79 

39 

219 

TARCOM 

67 

79.5 

84 

0 

■era 

179 

TSARCOM 

39 

93.5 

85 

0 

137 

186 

RH 

364 

mm 

100 

0 

134 

230 

ASO 

222 

122.7 

98 

6 

— 

190 

SPCC 

139 

123.2 

76 

0 

mtm 

188 

UHH 

361 

122.9 

90 

3 

155 

188 

OCALC 

■B| 

122.1 

107 

5 

BH 

207 

OOALC 

191.0 

88 

88 

■»■ 

246 

SAALC 

189.6 

145 

28 

.  ■ 

246 

SMALC 

152.7 

77 

52 

170 

242 

WRALC 

154 

154.4 

99 

58 

152 

246 

Air 

Force 

■9 

167.3 

114 

42 

156 

246 

Marine 

Corps 

103 

106.1 

65 

16 

101 

187 

DCSC 

3,818 

109.2 

91 

0 

134 

190 

DESC 

11,466 

124.8 

92 

0 

172 

192 

DGSC 

5,847 

133.6 

82 

14 

173 

198 

DISC 

6,995 

117.5 

93 

1 

163 

198 

DLA 

HH89 

1 

122.7 

90 

2 

169 

198 

GSA 

229 

109.4 

80 

0 

130 

200 

Total 

mmm 

123.3 

91 

2 

168 

198 

Source:  DODSSR  Data  Collection,  Main  Population 
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Statistics  were  obtained  for  production  and 
administrative  leadtimes  for  DLA  Centers.  This  data  is  shown  in 
Figure  1-108. 


DLA  SUPPORT  LEADTIMES 
(Number  of  Days) 


IMM 

Production 

Administrative 

DCSC 

96 

308 

DESC 

112 

318 

DGSC 

178 

94 

27  2 

DISC 

208 

100 

308 

Source:  Mid-Year  DLA  Budget  Submission 


Figure  1-108 

A  comparison  of  the  average  times,  variances 
from  the  averages  in  Figure  1-106  and  1-107  with  the  average  sup- 
ort  leadtimes  for  DLA  indicates  that  it  would  be  difficult  to 
eet  the  DRPR  need  times  in  the  majority  of  cases  if  the  item  was 
not  already  stocked  with  materiel  on  hand.  Currently  DLA  does 
not  consider  the  DRPR  if  the  item  has  an  NSN  already  assigned. 
Assuming  that  leadtimes  are  evenly  distributed  across  NSN  and 
part  numbered  items,  it  is  easy  to  see  why  DLA  is  providing  new 
support  dates,  YX  advice,  for  a  number  of  requests. 

It  is  concluded  that  either  the  SICCs  are  not 
sending  the  SSRs  early  enough  to  permit  a  realistic  support  lead- 
time,  the  production  and  administrative  leadtimes  are  too  high, 
or  a  combination  of  both  circumstances  prevails. 

(2 )  Initial  Accept  Time 

Initial  accept  time  is  computed  by  matching  con¬ 
tiguous  request  and  accept  advice  transactions  where  the  advice 
transaction  did  not  also  provide  an  NSN.  The  time  is  computed  by 
subtracting  the  date  of  receipt  of  the  request  from  the  date  of 
advice.  Times  were  computed  by  SICC  and  by  IMM.  The  differences 
by  ST CC  were  not  significant  so  only  the  times  for  IMM  are  dis¬ 
played  in  Figure  1-109. 

The  SSR  Procedures  specify  that  Initial  advice 
is  to  be  provided  within  25  days  of  the  receipt  of  the  request. 

The  statistics  indicate  that  this  is  being  accomplished  80X  of 
the  time  within  the  25-day  prescribed  timeframe,  90X  are  completed 
within  33  days,  95%  within  47  days,  and  99Z  within  131  days.  Ten 
percent  of  the  transactions  are  well  outside  the  specified  time¬ 
frames.  The  average  event  completion  times  for  NSN  and  part 
numbered  items  are  very  similar. 
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The  average  event  completion  times  and  902-ILE 
rates  for  SMALC  and  GSA  are  veil  above  the  norm.  These  differ¬ 
ences  are  attributed  to  activity  differences.  Since  these  are 
initial  accept  transactions  with  no  intervening  transactions  be¬ 
tween  the  request  and  the  advice,  it  would  appear  that  802  com¬ 
pleted  within  the  standard  is  too  low.  A  goal  should  be  estab¬ 
lished  and  a  monitoring  system  implemented  to  improve  processing 
in  this  area. 

(3)  Initial  NSN  Accept  Time.  This  time  category 
occurs  when  an  NSN  is  supplied  at  the  same  time  initial  accep¬ 
tance  is  provided.  As  shown  in  Figure  1-110  the  average  advice 
is  provided  within  the  25  day  timeframe;  622  are  provided  in  25 
days,  902  in  34  days,  952  in  37  days,  and  992  in  47  days.  The 
times  are  slightly  better  than  for  initial  advice  without  an  NSN. 
The  observations  for  GSA  are  too  low  to  be  significant. 

PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
INITIAL  NSN  ACCEPT  TIME 


I  MM 

Number 

Obser¬ 

vations 

Number  of 

Days 

Mean 

Std 

Devia¬ 

tion 

102- 

lle 

502- 

ile 

902- 

ile 

2,629 

18.3 

6 

13 

17 

25 

7  ,291 

25.0 

8 

18 

24 

35 

1,465 

20.7 

6 

14 

21 

27 

DISC 

4,285 

26.9 

9 

18 

26 

37 

DLA 

eeh  i 

24.0 

8 

15 

23 

34 

GSA 

6 

60.8 

28 

11 

54 

90 

Total 

K— 

24.0 

8 

15 

23 

34 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-110 

(4)  Final  NSN  Accept  Time 

This  category  occurs  when  a  part  numbered  item 
has  been  requested,  and  Initial  accept  advice  has  been  provided 
and  the  final  advice  provides  the  NSN.  There  are  60  days  allowed 
to  complete  these  actions.  No  other  events  occurred  between 
these  transactions.  Figure  1-111  provides  statistics  on  this 
category . 
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PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
FINAL  NSN  ACCEPT  TIME 


IMM 

Number 

Obser¬ 

vations 

Number  of 

Days 

Mean 

Std 

Devia¬ 

tion 

10%- 

ile 

50%- 

ile 

90%- 

ile 

ARRCOM 

1 

76.0 

0 

76 

76 

76 

CERCOM 

6 

0.0 

0 

0 

0 

0 

TARC0M 

2 

30.5 

9 

24 

24 

37 

Army 

9 

15.2 

27 

0 

0 

76 

DCSC 

326 

42.4 

12 

30 

41 

55 

DESC 

1,033 

52.1 

18 

34 

53 

71 

DGSC 

77 

46.4 

16 

31 

47 

62 

DISC 

1,430 

60.2 

15 

45 

60 

76 

DLA 

2,866 

54,9 

17 

37 

54 

73 

GSA 

25 

53.9 

35 

14 

48 

129 

Total 

2,900 

54.7 

17 

37 

54 

73 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  I —  1 1 1 

As  Is  the  case  with  Initial  acceptance,  this 
category  does  not  vary  significantly  by  submitter.  The  low  num¬ 
ber  of  observations  is  partly  attributable  to  the  fact  that  no 
intervening  transactions  were  permitted  in  the  computation  since 
chains  were  measured  as  part  of  a  separate  analysis.  The  volumes 
for  GSA  and  the  Service  WIMMs  are  too  low  to  be  significant.  The 
average  total  completion  time  was  54.7  days;  67 %  were  completed 
in  the  60  days  allotted  timeframe,  90%  in  73  days,  95%  In  85  days, 
and  99%  in  100  days.  Since  no  intervening  transactions  were  per¬ 
mitted  in  this  computation,  it  would  appear  that  more  than  67%  of 
this  event  should  have  been  completed  within  60  days. 

(5)  NSN  Need  Time.  The  SSR  Procedures  provide  that 
the  IMM  has  60  days  to  obtain  and  provide  an  NSN.  If  the  SICC 
requires  NSNs  in  less  than  60  days  after  receipt  of  the  request 
by  the  IMM,  the  SICC  may  enter  the  date  NSNs  are  required  in  the 
program  data  card.  A  review  of  42,568  program  data  cards  was 
conducted.  There  were  3,581  cards  or  8.4%  containing  data  in  the 
NSN  Need  Data  field.  Of  this  number  20%  were  invalid.  The  valid 
dates  were  processed  by  subtracting  the  DOR  from  the  NSN  Need 
Date.  The  average  time  from  this  computation  was  55  days.  Since 
the  IMM  is  allotted  60  days  to  provide  an  NSN,  and  there  is  a  low 
usage  rate  of  this  data  element  with  a  20%  error  rate,  this  data 
element  should  be  considered  for  elimination. 
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(6)  NSN  Time.  The  SSR  Procedures  allow  25  days  to 

provide  Initial  advice  for  a  part  numbered  Item  and  a  total  of  60 

days  to  provide  an  NSN  for  a  part  numbered  Item  from  the  date  the 

request  is  received.  If  the  first  25  days  are  used  to  provide  the 
initial  advice,  then  60  minus  25  days  or  35  days  remain  to  request 
and  obtain  an  NSN  after  the  initial  advice.  If  the  date  of  the 
initial  advice  is  subtracted  from  the  date  of  the  NSR  advice  an 
approximation  of  the  time  to  request  and  obtain  an  NSN  from  DLSC 
is  available.  This  is  an  approximation  of  the  time  to  prepare  an 
NSN  request,  forward  the  request  to  DLSC,  receive  an  NSN  from  DLSC 
and  process  the  NSN  through  file  maintenance  and  prepare  an  NSN 
advice.  This  time  was  extremely  consistent  by  SICC  and  IMM.  It 
took  an  average  of  22  days  to  accomplish  these  actions.  Ten  per¬ 
cent  were  completed  in  nine  days,  502  in  17  days,  86%  in  35  days, 

90%  in  40  days,  95%  in  48  days,  and  99%  in  191  days.  Since  86% 

were  completed  in  35  days,  this  means  that  14%  took  more  than  the 
allowed  time  for  completion.  Some  of  these  requests  are  taking 
far  too  long  to  go  through  the  NSN  assignment  process. 

(7)  Offer  Time.  The  offer  time  is  computed  by  sub¬ 
tracting  the  date  of  receipt  of  the  request  from  the  date  of  the 
offer.  The  IMM  is  allowed  25  days  from  date  of  receipt  in  which 
to  make  an  offer.  Figure  1-112  shows  the  time  required  by  the 
IMMs  to  make  an  offer.  The  average  time  to  make  an  offer  was  19 
days.  It  took  25  days  to  complete  44%,  32  days  to  complete  75%, 

39  days  for  90%,  45  days  for  95%,  and  61  days  for  99%.  These  are 
cases  where  no  initial  advice  preceded  the  offer.  For  some  reason, 
DISC  is  significantly  above  the  average  timeframes.  With  the  50% 
at  26  days,  over  50%  of  the  offers  exceed  the  25-day  timeframe. 

PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
OFFER  TIME 
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St  d 
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ile 
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OCALC 

1 

15.0 

0 

15 

15 

15 

Air 

Force 

1 

15.0 

0 

15 

15 

15 

DCSC 

108 

25.5 

12 

mm 

23 

37 

DESC 

9,121 

17.7 

36 

26 

38 

DGSC 

562 

23.7 

9 

23 

32 

DISC 

657 

31.1 

17 

32 

48 

DLA 

10,448 

18.9 

34 

5 

26 

39 

GSA 

22 

27.2 

29 

0 

15 

80 

Total 

10,471 

19.0 

34 

5 

26 

39 

Source:  D0DSSR  Data  Collection;  Main  Population 


Figure  1-112 
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A  SICC  Is  allowed  60  days  from  Che  date  of  an 
offer  from  an  IMM  to  reply  Indicating  acceptance  or  rejection  of 
the  offer.  As  was  noted  previously,  a  number  of  the  CX2  replies 
were  manually  processed  and  mailed;  therefore,  the  volumes  for 
this  event  are  quite  low.  Since  the  time  is  computed  from  the 
date  of  advice,  those  transactions  that  were  mailed  would  take 
even  longer  than  shown  in  Figure  1-113.  The  average  reply  time 
by  submitter  was  49  days.  There  were  84%  complete  within  the  60- 
day  timeframe,  90%  complete  within  89  days  and  99%  complete  in 
214  days.  But  it  took  from  90  to  214  days  to  complete  10%  of  the 
replies.  It  appears  that  this  process  is  much  too  long  consider¬ 
ing  that  over  86%  of  all  the  offers  are  for  items  that  already 
have  NSNs  and  that  over  97%  of  all  the  offers  are  accepted. 


PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
REPLY  TIME 
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95 
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24 

24 

24 
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15 

34.9 

17 

16 

30 

65 
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2 

13.0 

18 

0 

0 

26 

mm 

36 

40.8 

28 

11 

32 

88 
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241 

74.2 

28 

wm 

69 

135 

HH 

241 

m 

28 

57 

69 

SAALC 

mm 

— 

20.2 

10 

8 

19 

37 

SMALC 

l 

51.2 

40 

27 

40 

94 

WRALC 

55.1 

53 

21 

37 

174 

Air 

Force 

50.0 

40 

24 

40 

94 

Marine 

Corps 

180 

warn 

22 

0 

6 

15 

Other 

57 

38.8 

45 

11 

13 

mm 

Total 

mmm 

49.2 

40 

20 

40 

89 

Source:  DODSSR  Data  Collection;  Main  Population 


It  should  be  noted  that  the  Air  Force  has  a  Cen¬ 
tral  Cataloging  and  Standardization  Office  (CASO)  at  Battle  Creek, 
Michigan,  that  performs  cataloging  and  item  entry  control  func¬ 
tions  that  are  performed  by  SICCs  in  the  other  Services.  During 
the  course  of  the  study,  IMMs  forwarded  offers  to  CASO  for  review 
and  approval.  After  CASO  performed  the  review,  the  offer  package 
consisting  of  the  Standard/Alternate  Referral  (DLA  Form  546)  and 
any  associated  technical  data  was  forwarded  to  the  cognizant  ALC, 
to  update  their  files  and  to  prepare  a  CX2  Reply  To  Offer  to  the 
IMM  to  accept  or  reject  the  offer.  During  field  research,  the 
study  team  requested  a  sample  of  DLA  Forms  546  to  analyze  to  deter¬ 
mine  if  this  extra  "leg'*  was  adding  to  the  time  for  Air  Force 
ALCs  to  reply  to  offers.  The  analysis  of  the  dates  for  comple¬ 
tion  of  IMM,  CASO  and  ALC  actions  indicates  that  an  average  of  12 
days  1 8  attributable  to  the  time  from  completion  of  the  CASO  re¬ 
view  until  received  by  the  ALC.  It  is  understood  that  the  Air 
Force  has  since  corrected  this  condition  by  providing  for  CASO  to 
prepare  a  CX2  reply  for  direct  transmittal  to  the  IMM  with  the 
Form  546  package  sent  to  the  ALC  for  file  maintenance  purposes. 

(9)  Pending  Time.  Pending  advice  is  generally  pro¬ 
vided  within  the  25  days  allowed  time.  There  were  so  few  pending 
advices  used  that  the  volumes  are  too  small  to  warrant  a  sta¬ 
tistical  display. 


Followup  Time 


The  SSR  Procedures  permit  SICCs  to  followup  for 
Initial  advice  after  35  days  have  elapsed  from  the  submission  of 
the  request  and  70  days  for  an  NSN  advice.  Figure  1-114  provides 
data  on  followups  based  upon  the  time  from  the  submission  of  the 
request  until  the  time  the  followup  is  generated.  The  Air  Force 
sent  out  almost  90%  of  all  the  followups.  The  Air  Force  system 
provides  for  followups  to  be  sent  out  40  days  after  the  DOR  for 
initial  advice  and  75  days  for  NSNs .  However,  the  DOR  is  the 
date  the  SSR  was  generated  in  the  Air  Force  with  additional  time 
reqired  to  match  SSRs  with  technical  data  and  to  prepare  and  mall 
the  requests.  The  other  Services  allow  at  least  10  more  days 
prior  to  followup  than  the  Air  Force.  About  50  to  60Z  of  the 
f o 1 lo wups  were  for  NSNs  and  40  to  50%  were  for  initial  advice. 
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PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
FOLLOWUP  TIME  (SUB  DATE) 
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31 
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11 

70 

73 

92 
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2 
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17 
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189 

MIRCOM 

3 
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59 

117 
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56 
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21 

51 

92 

117 
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14 
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11 

105 

105 

124 

mm 

106 

mm 

28 

64 

92 

120 

ASO 

78.0 

18 

48 

81 

90 

mm 

mm 

78.0 

18 

48 

81 

90 

OCALC 

49 

40.9 

4 

35 

42 

49 

OOALC 

623 

63.4 

14 

40 

72 

72 

SAALC 

3,300 

59.2 

19 

35 

70 

70 

SMALC 

7,083 

50.8 

17 

35 

40 

70 

WRALC 

2,070 

60.5 

16 

35 

70 

70 

Air 

Force 

55.0 

18 

35 

70 

70 

Marine 
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60.4 

23 

9 

64 

88 

Other 

61 

IBM 

33 

30 

83 

83 

Total 

nn 

— 

57.2 

19 

35 

70 

72 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-114 

Figure  1-115  was  generated  to  attempt  to  relate 
followup  times  to  the  time  the  SSR  was  received  by  thq  IMM.  About 
40  to  50X  of  the  time  the  Air  Force  was  following  up  in  26  days 
or  less  when  the  SSR  Procedures  specify  35  days  from  date  of  sub¬ 
mission.  Since  the  Air  Force  uses  the  DOR  as  the  starting  point 
instead  of  the  actual  date  of  submission,  the  IMM  often  is  not 
receiving  its  full  25  days  to  process  the  request.  In  some  cases, 
when  the  mall  time  is  lengthy,  the  SSR  may  not  have  been  placed 
in  the  suspense  files,  so  the  followup  generates  a  "No  Record" 
response.  The  Air  Force  then  generates  another  SSR  and  submits 
it  which  may  result  in  the  processing  of  duplicate  requirements 
by  the  IMM. 
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PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
FOLLOWUP  TIME  (REC  DATE) 
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83 
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Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-115 

(11)  Response  Time.  The  IMM  Is  allowed  15  days  from 
the  receipt# of  a  followup  to  provide  a  response.  Almost  99.6% 
of  the  followups  were  sent  to  DLA.  The  volumes  for  the  Services 
as  WIMM8  was  too  small  to  be  significant.  The  statistics  for  DLA 
and  the  overall  statistics  which  are  dominated  by  DLA  volumes 
indicate  that  the  responses  are  sent  out  1/  DLA  in  an  average  of 

i  one  day. 

(12)  Offer  Withdraw  Time.  The  IMM  may  send  a  CXI 
advice  card  with  an  ATC  08  if  a  reply  to  an  offer  has  not  been 
received  within  60  days  of  the  date  of  the  offer.  There  is  no 
10-day  transmission  time  allowance  as  in  the  case  of  initial 
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advice  (25-day  expected  reply,  35-day  followup)  and  NSN  advice 
(60-day  expected  reply,  70-day  followup).  The  only  statistics 
in  the  data  base  for  IMMs  was  for  DLA.  The  mean  time  between  the 
Offer  and  CXI  ATC  08  transaction  was  76.6  days  which,  is  well  over 
the  60  days  time  allowed.  Indicating  that  DLA  is  waiting  the  proper 
amount  of  time  before  rejecting  the  SSR  when  there  has  been  no 
response  to  an  offer.  The  10th  percentile  showed  67  days,  50th 
percentile  was  68  days  and  the  90th  percentile  82  days. 

( 13 )  Reject  Time 

Reject  time  is  the  time  it  takes  to  review  a 
request  from  the  time  of  receipt  until  the  date  of  the  reject 
advice.  Reject  time  is  a  function  of  the  type  of  reject  and  the 
IMM.  The  time  to  process  rejects  does  not  appear  to  vary  signif¬ 
icantly  by  SICC.  Figure  1-116  provides  processing  times  for  re¬ 
jects  by  reject  category.  The  total  main  population  was  used 
because  the  statistics  are  quite  consistent  from  population  to 
population  except  for  the  match/duplicate  category.  The  Steady 
State  figures  for  this  category  were  mean  (10.4),  50%-ile  (6), 
and  90%-ile  (25)  . 

PROCESSING  TIMES  FOR  EVENT  TIME  TYPE 
(Rejects  by  Category) 
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FSC/Manager 

21.8 

20 

37 

NSN/PSCN 

19.7 

12 

31 

Catalog/TD 

23.5 

22 

35 

Invalid  Data 

5.1 

5 

13 

Match/Duplicate 

14.5 

15 

21 

Procurement 

24.2 

22 

37 

Other 

28.8 

24 

46 

Total 

16.9 

12 

33 

Source:  D0DSSR  Data  Collection;  Main  Population 


Figure  1-116 

The  statistics  are  heavily  dominated  by  DLA  due 
to  the  volume  of  SSRs  received  and  processed  by  DLA.  There  was 
quite  a  variance  above  and  below  the  means  in  all  categories  for 
Service  WIMMs  and  for  GSA  as  a  CIMM.  However,  the  volumes  for 
the  Services  and  GSA  by  reject  category  and  total  rejects  is  so 
small  in  comparison  with  DLA  that  it  is  difficult  to  determine 
the  statistical  significance  of  their  data. 


155 


* 


The  FSC/Manager  and  NSN/PSCN  categories  are  the 
result  of  DLSC  screening,  whereby  the  IMM  has  picked  up  informa¬ 
tion  from  DLSC  files  Indicating  that  the  FSC  is  not  in  a  class 
managed  by  the  IMM,  the  item  has  been  routed  to  the  wrong  IMM  or 
there  is  a  pick  up  of  an  NSN  for  a  part  numbered  item  or  some 
other  inconsistency  between  the  data  in  DLSC  files  and  the  SSR. 

At  DLA,  the  SSR  is  validated  after  receipt.  If  the  transaction 
falls  validation,  an  Invalid  data  reject  advice  is  created  and 
routed  to  AUTODIN  for  transmission  to  the  SICC.  It  is  logical, 
therefore,  that  the  invalid  data  category  is  the  lowest  of  all. 

If  the  SSR  passes  validation,  a  DLSC  screening 
request  transaction  is  created  by  the  provisioning  subsystem  and 
passed  to  the  technical  subsystem  for  updating  the  screening 
suspense  file  and  creation  of  a  screening  transaction  to  be  for¬ 
warded  to  DLSC  via  AUTODIN  using  DIDS  Priority  2.  DIDS  Priority 
2  requires  a  12-hour  response  time  from  DLSC.  This  breaks  down 
into  two  hours  transmission  time  to  DLSC,  eight  hours  combined 
terminal  and  computer  DLSC  processing  time  and  two  hours  trans¬ 
mission  time  from  DLSC  to  the  IMM.  After  the  reply  is  received 
from  DLSC,  it  is  routed  to  the  technical  subsystem  to  update  the 
suspense  file  and  then  routed  to  the  provisioning  subsystem  where 
the  reject  advice  is  generated  for  routing  to  the  SICC  via 
AUTODIN. 

The  two  weeks  plus  differential  between  the  time 
for  an  invalid  data  reject  and  the  DLSC  screening  reject  cate¬ 
gories  (FSC/Manager  and  NSN/PSCN)  is  much  too  large.  This  is 
attributed  to  a  combination  of  internal  processing  time  at  both 
the  IMM  and  DLSC  to  generate  the  screening  request,  process  the 
screening  request  and  process  the  reply.  We  could  not  Isolate 
the  times  attributable  to  DLSC  and  that  to  the  IMM,  because  this 
type  of  time  tracking  could  not  be  obtained  from  either  the  IMMs 
or  DLSC.  The  local  procedures  and  operations  for  internal  sched¬ 
uling,  wait  times  and  processing  times  should  be  reviewed  at  both 
the  IMMs  and  at  DLSC.  The  mean  time  for  FSC/Manager  rejects  at 
DESC  and  DISC  were  about  a  week  higher  than  for  the  other  Centers. 
DESC  was  almost  two  weeks  higher  than  DCSC  and  one  week  higher 
than  DGSC  and  DISC  for  NSN/PSCN  rejects. 

Provisioning  screening  is  also  a  driving  factor 
in  the  times  for  Catalog/TD,  Procurement  and  Other,  in  that  trans¬ 
actions  are  screened  prior  to  the  manual  review  actions  performed 
by  the  IMMs  on  these  categories.  The  Other  category  requires  the 
preparation  of  "in  the  clear"  exception  data  that  must  be  manually 
prepared  and  thus  adds  an  additional  week  of  processing  time. 

Here  again,  the  times  for  DESC  and  DISC  are  a  week  to  two  weeks 
higher  than  for  the  other  Centers. 
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The  Match/Duplicate  category  is  10  to  20  days 
higher  than  the  other  Centers*  It  appears  as  if  there  is  some 
manual  processing  being  introduced  at  DESC  for  this  category. 

(14)  Resubmit  Time.  The  SSR  Procedures  do  not  cur¬ 
rently  specify  timeframes  for  the  resubmission  of  an  SSR  after  a 
request  has  been  rejected.  The  patterns  of  731  reject  chains 
from  the  data  base  were  analyzed  to  determine  the  amount  of  time 
it  took  from  the  date  a  reject  was  submitted  by  an  IMM  until  the 
date  the  SICC  resubmitted  the  request.  The  results  of  this  anal¬ 
ysis  indicated  that  it  took  an  average  of  46  days  resubmit  time 
with  50%  completed  within  27  days  and  90%  resubmitted  within  107 
days . 

d .  Life  Cycle  Analysis 

Previous  sections  in  this  Chapter  discussed  the  dif¬ 
ferent  types  of  SSR  transactions  and  how  the  transactions  are 
grouped  together  to  form  transaction  chains.  Symbolic  and  simpli¬ 
fied  SSR  transactions  were  described  and  times  were  computed  for 
submission  of  individual  transactions  and  for  accomplishment  of 
Individual  events.  Although  the  SSR  procedures  specify  timeframes 
for  completing  various  events  and  activities  concern  themselves 
with  providing  advice  in  25  days,  NSN  in  60  days,  following  up  in 
35  days  and  providing  responses  in  15  days;  these  are  merely 
pieces  of  the  total  picture  of  the  supply  support  process.  The 
activity  requesting  support  for  an  item  is  concerned  not  merely 
with  receiving  a  reject  in  25  days  or  response  in  15  days  but  is 
really  concerned  with: 

***  "When  am  I  going  to  get  support?" 

***  "How  long  does  it  take  to  get  support?” 

***  "How  much  effort  does  it  involve  to  obtain  support?" 


The  real  question  relates  to  the  final  supply  support 
decision  which  is  a  sum  total  of  all  the  individual  combinations 
of  events  that  have  transpired  from  the  initial  request  until  the 
final  support  decision.  All  the  individual  transactions  in  the 
life  cycle  of  an  SSR  could  be  processed  within  specified  time- 
frames  and  support  could  still  be  jeopardized  if  the  total  life 
cycle  time  was  too  long.  This  section  analyzes  life  cycle  times 
in  an  effort  to  determine  just  how  effective  is  supply  support. 

( 1 )  Network  or  Chain  Patterns 

A  listing  was  produced  showing  each  of  the  dif¬ 
ferent  (net)  chains  with  the  three-digit  code  indicating  each  of 
the  events  and  subevent  types  in  the  chain.  Counts  of  the  oc¬ 
currence  of  each  of  the  net  chains  (gross  number  of  chains)  was 
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provided  for  each  of  the  different  chains*  The  chains  were  re¬ 
viewed  to  determine  those  that  were  logical  or  illogical,  complete 
or  incomplete,  open  or  closed,  correct  or  incorrect,  and  for  fre¬ 
quency  of  occurrence.  Chains  that  were  similar  were  grouped  into 
chain  patterns  for  analysis  and  timing  purposes.  Generally  chains 
that  were  logical,  complete  and  with  a  significant  volume  were  in¬ 
cluded  for  analysis.  The  following  types  of  chains  were  excluded. 

Chains  Not  Beginning  With  A  Request.  A  chain  must  begin 
ith  a  request  to  be  meaningful.  Chains  without  a  request  either 
ave  the  request  missing  from  the  data  base  or  the  request  oc¬ 
curred  in  an  earlier  period. 


Single  Transaction  Chains  were  excluded  because  there  is 
no  way  of  measuring  times  without  at  least  two  transactions  to 
represent  the  completion  of  an  event.  Examples  of  these  are 
requests  that  occurred  at  the  end  of  the  data  collection  period 
or  advice  transactions  that  occurred  at  the  beginning  of  the 
period  but  referred  to  a  request  transaction  from  a  previous 


period . 


they 
t  rol 


Chains  With  Repeating  Transactions  were  excluded  because 
were  illogical  and  represent  duplicate  transactions  or  con- 
data  . 


Open  Or  Incomplete  Chains  were  generally  excluded  because 
a  final  time  could  not  be  computed  or  represented  chains  that 
occurred  during  the  end  of  the  data  collection  period  and  there 
was  not  enough  time  to  close  out  the  chain. 


Illogical  Chains  are  those  that  simply  do  not  make  sense 
and  should  not  occur.  These  chains  either  have  duplicate  trans¬ 
actions  due  to  the  application  of  control  data  or  have  missing 
events  in  the  chain.  Volumes  of  these  chains  were  low. 


Chains  With  Repeating  Transactions.  These  chains  would 
require  extensive  Individual  analysis  to  determine  usability. 
These  chains  include  those  that  have  complete  duplicates,  those 
with  duplicate  control  data  for  different  items  of  supply,  those 
with  partial  duplicate  control  data  but  with  different  dates  of 
request,  or  represent  changes  to  an  original  request  without  an 
identifying  type  of  change  code. 

Low  Volume  Chains  were  excluded  even  though  they  may  have 
been  logical  if  they  could  not  fit  into  one  of  the  group  patterns 
and  if  their  measurement  would  not  have  significantly  contributed 
to  the  analysis. 
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The  chains  were  grouped  Into  major  categories  of 
chain  patterns  using  a  "Dominant  Event  Concept.”  Under  this  phi¬ 
losophy,  the  dominant  event  is  the  one  that  controls  the  outcome 
of  support  decision  or  significantly  influences  the  chain  cycle. 
The  major  chain  categories  with  their  associated  chain  patterns 
that  were  selected  for  analysis  are  shown  below.  Processing 
times  for  the  chain  patterns  or  networks  were  computed  using  the 
dates  of  receipt  of  the  first  request  transaction  and  dates  of 
submission  of  the  last  advice  transactions  in  the  network  pat¬ 
terns. 


(a)  Accept  Chain  Network  Patterns.  Included 
are  chains  with  a  request  and  an  accept,  but  there  may  be  follow¬ 
ups  because  of  the  delay  in  the  acceptance  or  loss  of  the  accep¬ 
tance  transactions.  Even  though  a  request  may  have  been  accepted 
by  an  IHM,  it  is  not  complete  until  the  acceptance  is  communicated 
by  the  1MM  and  received  by  the  SICC.  The  chain  patterns  are  shown 
by  the  events  listed  in  order  of  occurrence  in  the  chain  as  shown 
be  low . 


l_  Request 
2_  Request 
3^  Request 

Response  -  Final  Accept 

4^  Request 
5_  Request 

Followup  -  Response 


-  Accept 

-  Interim  Accept  -  Final  Accept 

-  Interim  Accept  -  Followup  - 

-  Accept  -  Followup  -  Response 

-  Accept  -  Followup  -  Response 


Request  -  Accept  -  Followup  -  Response 
Followup  -  Response  -  etc. 

7_  Request  -  Initial.  Accept  -  Followup  - 
Response  -  Final  Accept  -  Response 


(b)  Offer  Chain  Network  Patterns.  Although 
there  are  followups  and  rejects  in  these  chains,  the  offer  is 
considered  the  dominant  event.  Rejects  are  those  related  to 
offers  that  have  not  been  accepted  within  60  days. 


Request 
Request 
_3  Request 
4^  Request 


Offer  -  Reply 
Offer  -  Support  Reject 
Offer  -  Reply  -  Accept 
Offer  -  Reject  -  Reply 
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Accept 

5 

Request  -  Offer  - 

Reject  -  Request  - 

Reply 

6 

Request  -  Followup 

-  Response  -  Offer 

Reply  -  Accept 

_7 

Request  -  Followup 

-  Response  -  Offer 

Re  jec  t 

8 

Request  -  Offer  - 

Reject  -  Request  - 

Request  -  Accept 

9 

Request  -  Offer  - 

Reply  -  Reject  - 

(c) 

Reject  Chain  Network 

Patterns.  Sone  of 

reject  patterns  were  further  broken  down  into  their  reject  sub- 
categories  for  report  purposes*  This  distinction  is  shown  in  the 
statistical  tables  wherever  the  data  for  a  reject  subcategory  was 
significant . 


JL  Request  -  Reject 

2  Request  -  Reject  -  Request  -  Accept 

_3  Request  -  Reject  -  Request  -  Initial 
Accept  -  Final  Accept  (Note:  Further  subdivided  by  reject  sub¬ 
categories) 


_4 

etc*  -  Request  -  Accept 

Request 

-  Reject  -  Request 

-  Reject  - 

Request  -  Accept 

5 

Request 

-  Reject  -  Followup 

-  Response  - 

6 

Request 

-  Reject  -  Followup 

-  Response 

7_  Request  -  Reject  -  Request 
(Note:  Further  subdivided  by  reject  subcategories) 

-  Reject 

Request  -  Reject  - 
categories) 

8 

etc  • 

Request 
(Note  : 

-  Reject  -  Request 
Further  subdivided 

-  Reject  - 
by  reject  sub 

Followup  -  Response 

9 

Request 

-  Reject  -  Request 

-  Reject  - 

Followup  -  Response 

10 

Request 

-  Reject  -  Followup 

-  Response  - 
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1 1  Request  -  Reject  -  Followup  -  Response  - 
Followup  -  Response  -  Request  -  Accept 

( d)  Followup  Chain  Network  Patterns 

These  chains  are  dominated  by  the  followup. 
The  reject  If  present  occurs  only  after  a  followup,  response,  and 
resubmission  of  a  request. 


2  Request  -  Followup  -  Response 
(Note:  This  category  was  further  subdivided  into  No  Record  and 

other  types  of  responses.) 


2 

Request 

-  Followup  -  Response  -  Follow- 

up  -  Response 

3 

Request 

-  Followup  -  Response  -  Follow- 

up  -  Response  -  Et 

c . 

4 

Request 

-  Followup  ~  Response  -  Request 

Re  jec t 

2 

Request 

-  Followup  -  Response  -  Accept 

Request  -  Accept 

6 

Request 

-  Followup  -  Response  -  Request 

Reject  -  Request  - 

Accept 

Life  cycle  processing  times  were  computed 
for  each  of  the  network  patterns  and  the  results  are  displayed  by 
category  as  shown  in  the  tables  that  follow.  The  chain  network 
patterns  shown  above  were  codified  for  Inclusion  in  the  tables 
for  the  purpose  of  brevity.  The  codes  used  and  their  definitions 
are  shown  below: 


Code 

Definition 

AA 

Advice  indicating  acceptance 

of  supply 

support . 

AF 

Advice  providing  final  suppor 

t  acceptance. 

AI 

Advice  providing  initial  supp 

ort  acceptance. 

AN 

Advice  accepting  support  and 

providing 

NSN. 

AO 

Advice  providing  an  offer  of 

substitute 

to  item 

requested . 

AR 

Advice  providing  reject  of  supply  support  request 

AH 

Advice  accepting  support  and 

does  not  provide  NSN 

FA 

Followup  for  advice. 

RF 

Response  to  followup. 

RO 

Reply  to  offer. 

RS 

Request  for  supply  support. 

ETC 

Indicates  that  the  repeating 

codes  may 

iterate  a 

number  of  times. 


(2)  Accept  Networks.  Networks  for  chein  patterns 
indicating  a  basic  acceptance  of  an  SSR  are  shown  in  Figure  1-117. 
The  general  patterns  is  one  of  acceptance,  but  the  original  accep¬ 
tance  may  have  been  lost  in  transmission  or  received  after  the 
allowed  timeframe.  To  the  extent  that  the  support  advice  is 
missing,  lost,  delayed,  or  Improperly  recorded  in  control  files, 
the  SICC  advice  processing  phase  is  delayed,  with  possible  affect 
on  the  decision  to  field  or  not  to  field  a  particular  piece  of 
equipment.  The  communication  of  the  support  advice  is  effective 
on  an  average  within  the  25-day  allotted  timeframe  for  67.3%  of 
all  the  accept  chains.  As  the  number  of  transactions  in  the 
chain  increases,  the  longer  it  takes  to  communicate  the  advice 
decision.  In  at  least  4.2%  of  the  chains  there  has  been  more 
than  one  followup  indicating  a  breakdown  in  the  communications 
system.  In  those  cases  where  there  has  been  only  one  followup 
it  may  be  because  the  followups  was  sent  out  too  early  or  because 
the  advice  was  delayed.  It  should  be  noted  that  anywhere  from  75 
to  95%  of  the  follow  up  when  there  has  been  acceptance,  depend¬ 
ing  upon  the  chain  pattern,  are  attributable  to  the  Air  Force. 

This  is  due  to  a  combination  of  systems  used  to  generate  the  fol¬ 
lowup  and  to  communicate  the  request  and  followup  as  was  explained 
under  the  single  event  proces  lng  times  described  previously  in 
this  Chapter. 


PROCESSING  TIMES 
ACCEPT  CHAIN  NETWORK  PATTERNS 
(Number  of  Days) 


Number 

Obs. 

■Ml 

Chain  Network  Pattern 

Mean 

H9 

90%- 

ILE 

49,840 

62.2% 

RS-AW 

22.7 

15 

34 

12,117 

15.1 

RS-AN 

26.6 

23 

54 

8,861 

11.1 

RS-AI-AF 

41.6 

40 

57 

5,941 

7.4 

RS-AA-FA-RF 

50.7 

50 

108 

1,327 

1.7 

RS-AI-FA-RF-FA 

63.3 

60 

87 

954 

1.2 

RS-AA-FA-RF-FA-RF 

110.3 

115 

148 

1,025 

1.3 

RS-AA-FA-RF-FA-RF-Etc . 

169.2 

176 

186 

80.065 

100.0% 

Accept  Pattern  Total 

m 

nn 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-117 


(3)  Offer  Networks 


Figure  1-118  provides  the  results  of  the  com¬ 
puter  analysis  of  offer  networks.  The  nine  networks  shown  repre¬ 
sent  the  principal  offer  chain  patterns  that  can  and  did  occur 
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during  the  data  collection  period.  The  rejects  shown  in  the 
offer  chain  pattern  are  restricted  to  those  that  relate  specifi¬ 
cally  to  offers.  These  rejects  represent  the  support  rejects 
that  occur  when  an  offer  is  made  and  the  SICC  fails  to  respond 
within  60  days  of  the  offer. 

The  first  chain  represents  the  ideal  situation 
when  a  request  is  submitted,  an  offer  is  made,  and  a  reply  to  the 
offer  i 8  given  without  any  intervening  transactions  such  as  folio 
ups  or  rejects.  The  time  allowed  complete  this  chain  would  be  25 
days  to  make  the  offer  and  60  days  to  reply  to  the  offer.  The 
mean  time  from  the  table  is  66.4  days  with  90Z  complete  in  three 
days  over  the  allowed  time.  However,  the  table  indicates  that 
even  for  this  simple  offer  network  over  10Z  exceeds  the  allowed 
time  with  the  longest  chain  requiring  120  days  to  complete. 

PROCESSING  TIMES 
OFFER  CHAIN  NETWORK  PATTERNS 
(Number  of  Days) 


Number 
Obs  • 

Z 

Obs . 

Chain  Network  Pattern 

Mean 

50Z- 

ILE 

90Z- 

ILE 

826 

20. 9Z 

RS-AO-RO 

66.4 

67 

88 

713 

18.0 

RS-AO-RO-AN 

89.8 

86 

111 

167 

4.2 

RS-FA-RF-AO-RO 

77.4 

61 

138 

79 

2.0 

RS-FA-RF-A0-R0-AN 

99.5 

91 

134 

1,444 

36.6 

RS-A0-AR 

93.2 

92 

103 

257 

6.5 

RS-AO-AR-RO 

102.5 

100 

113 

132 

3.4 

RS-AO-AR-RS-AA 

112.9 

106 

159 

151 

3.8 

R-S-A0-AR-RS-AR 

140.7 

146 

192 

182 

4.6 

RS-A0-R0-AR-RS-AA 

183.3 

202 

209 

100. OZ 

Offer  Pattern  Total 

93.6 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-118 

The  second  chain  pattern  represents  the  case 
where  an  item  is  requested,  an  offer  is  made  and  accepted  and  an 
NSN  is  provided.  In  this  case  the  allowed  time  consists  of  25 
days  for  the  offer,  60  days  for  the  reply,  and  60  days  to  provide 
the  NSN  for  a  total  of  145  days  if  the  maximum  allowable  time  is 
used.  Almost  all  of  the  chains  are  completed  within  the  allowed 
time  of  145  days  which  consists  of  the  summation  of  the  time  for 
completing  individual  events.  The  maximum  time  for  the  longest 
chain  was  148  days.  But,  it  should  be  pointed  out  that  60  days 
are  allowed  from  the  time  of  the  request  to  the  NSN  advice  when 
the  original  item  is  supported.  This  means  that  there  are  25 
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days  for  the  Initial  advice  and  60  minus  25  days  or  35  days  in 
which  to  supply  the  NSN.  It  *ould  appear  that  60  days  is  too 
long  to  supply  an  NSN  when  the  original  request  has  already  been 
processed  and  the  offer  accepted. 

The  third  case  occurs  when  there  is  a  followup 
and  response  taking  place  prior  to  the  offer.  Actually  the  fol¬ 
lowup  does  not  do  anything  to  delay  the  offer  because  the  response 
is  usually  computer  processed  to  provide  status  that  is  in  the 
suspense  file.  So  this  case  really  represents  those  times  where 
the  offer  has  been  delayed  and  the  times  extended.  If  the  follow¬ 
up  had  not  been  generated,  the  chain  would  have  been  classified 
in  with  the  first  chain.  In  this  case  there  is  a  total  of  85 
days  to  accomplish  the  chain.  The  15-day  response  time  for  the 
response  to  the  followup  is  included  within  the  85  days.  No 
extra  time  is  allowed  for  the  response,  because  the  followup  is 
sent  out  because  the  initial  response  was  not  received  in  35  days 
and  no  additional  time  is  allowed  for  delinquency.  It  should  be 
noted  that  over  50%  of  the  transactions  are  completed  in  85  days, 
it  takes  138  days  to  complete  90%  of  the  chains,  and  the  longest 
chain  took  199  days. 

The  fourth  case  is  similar  to  the  second  case 
except  that  there  is  a  followup  and  response  introduced.  Accord¬ 
ing  to  the  current  rules,  145  days  are  allowed  to  complete  this 
chain.  Although  90%  are  completed  within  134  days,  it  takes  181 
days  to  complete  the  longest  chain  in  this  pattern. 

The  remainder  of  the  chains  represent  those 
cases  where  there  has  been  an  offer,  but  there  has  been  a  reject 
because  the  response  to  the  offer  has  not  been  offered  within  60 
days.  When  this  happens  a  new  request  must  be  submitted.  The 
introduction  of  the  reject  transaction  withdrawing  the  offer 
significantly  extends  the  time  for  completion  of  the  chain.  The 
time  may  be  extended  to  over  5  months  on  an  average  or  up  to  200 
days  or  more.  The  time  to  generate  and  communicate  the  offer  and 
to  receive,  process  and  communicate  the  reply  must  be  reduced  to 
improve  the  supply  support  process  when  there  is  an  offer  made  of 
a  substitute  item. 


( 4 )  Followup  Chains 


Figure 
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PROCESSING  TIMES 
FOLLOWUP  CHAIN  NETWORK  PATTERNS 
(Number  of  Days) 


Number 
Obs . 

% 

Obs . 

Chain  Network  Pattern 

Mean 

50%- 

ILE 

90%- 

ILE 

141 

7.2% 

RS-FA-RF-AA-RS-AA 

35.8 

32 

52 

1,245 

64.0 

RS-FA-RF 

49.0 

49 

65 

42 

2.2 

RS-FA-RF-RS-AR-RS-AA 

98.9 

79 

160 

60 

3.1 

RS-FA-RF-RS-AR 

105.9 

98 

158 

245 

12.6 

RS-FA-RF-FA-RF 

111.1 

109 

171 

212 

10.9 

RS-FA-RF-FA-RF-etc. 

179.3 

184 

186 

1.945 

100.0% 

Followup  Pattern  Total 

72.9 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-119 

It  should  be  noted  from  the  start  that  most  of 
the  followup  chain  patterns  are  dominated  by  the  Air  Force,  since 
the  Air  Force  sends  out  most  of  the  followups  from  its  automated 
system.  The  first  case  occurs  when  the  followup  Is  sent  out  and 
received  prior  to  the  request  being  received  and  lodged  In  the 
suspense  file.  A  No  Record  response  advice  is  sent  out  causing 
the  request  to  be  resubmitted.  When  the  first  request  is  received 
It  was  processed  and  accepted.  When  the  second  request  was  re¬ 
ceived,  It  also  was  processed  and  accepted  In  the  consideration 
of  duplicate  requests  for  support  occurring  at  different  times. 

The  second  case  occurs  when  the  followup  is 
received  and  processed  after  the  request  has  been  received  and 
recorded  in  the  suspense  file.  The  response  provides  status  on 
the  original  request  and  a  second  request  is  not  generated. 

The  third  case  Involves  both  a  followup  and  a 
reject.  There  are  three  requests  involved.  The  forwarding  of  an 
early  followup  results  in  the  resubmission  of  requests  with  a 
reject  of  the  first  one  and  final  accept  after  the  third  request. 
Processing  Is  hindered  by  the  lack  of  communication  of  the  sub¬ 
mitter  and  receiver  because  a  mix  of  transactions  occurs  that 
should  not  have  happened  because  of  timing  of  generation  of  fol¬ 
lowups  and  resubmission  of  requests.  This  merely  serves  to  delay 
support  as  is  evidence  by  the  99-day  average  and  over  160  days  to 
support  the  longest  chain. 

The  fourth  case  is  much  like  the  third,  except 
that  the  chain  has  not  yet  had  time  to  complete  itself,  yet  the 
average  chain  has  already  taken  over  105  days  with  no  support 


received.  The  last  two  cases  represent  a  true  breakdown  In  com¬ 
munications,  since  there  are  repeated  followups  and  responses  with 
up  to  six  months  transpiring  with  no  final  resolution.  Either 
transactions  are  not  being  received  by  the  intended  receiver  or 
records  in  the  suspense  files  are  not  being  generated,  stored  or 
retrieved  properly.  The  Air  Force  system  permits  records  to  be 
generated  using  the  same  control  data  on  the  same  or  different 
days.  This  allows  advice  to  be  recorded  on  the  incorrect  record 
and  followups  to  be  generated  for  records  on  which  advice  has 
already  been  received.  The  same  thing  can  happen  for  nonprovi¬ 
sioning  SSRs  for  the  other  Components,  since  the  same  PCC  and  ISN 
may  be  used  over  and  over  again. 


Based  upon  the  statistics  in  this 
appears  that  there  should  be  procedural  and  system 
concerning  the  structure  and  use  of  control  data  to 
store  and  retrieve  requests  and  the  timing  of  when 
will  be  generated. 


table,  it 
changes  made 
generate , 
followups 


(5)  Reject  Networks 


Reject  networks  are  depicted  in  Figure  1-120. 

The  first  case  is  almost  identical  to  the  single  event  time  shown 
under  single  events  earlier  in  this  Chapter.  It  is  shown  here 
for  comparison  purposes.  The  cases  shown  here  are  where  rejects 
are  dominant,  and  do  not  include  all  the  cases  of  rejects,  since 
some  rejects  occur  in  accept,  followup  and  offer  chains.  Rejects 
were  broken  down  into  reject  categories  for  some  of  the  reject 
chains,  but  they  have  been  summarized  here  since  the  same  results 
occurred  as  for  single  events;  therefore,  the  subcategories  are 
not  duplicated  here. 


The  same  phenomena  exists  for  reject  chains  as 
for  accept,  offer  and  followup  chains,  that  is,  as  the  chain 
contains  more  and  more  transactions  and  becomes  more  complex,  the 
time  to  complete  the  supply  support  cycle  lengthens.  The  chains 
shown  in  the  figure  contain  a  combination  of  requests,  resubmis- 
slons,  rejects,  followups  and  accepts.  The  average  time  for 
completion  of  these  chains  ranged  from  21  to  116  days.  It  took 
as  long  as  six  months  and  longer  maximum  time  to  complete  some  of 
the  longer  chains.  It  should  be  noted  however,  that  the  first 
case  is  incomplete,  since  it  ends  with  a  reject.  Unless  it  is  a 
final  reject  such  as  an  item  that  should  be  retained  for  Service 
management  or  is  in  a  class  outside  the  scope  of  the  SSR  Proce¬ 
dures,  the  request  must  be  resubmitted  and  the  chain  will  end  up 
in  one  of  the  other  cases  in  Figure  1-120.  The  time  to  complete 
a  reject  chain  is  directly  affected  by  the  number  and  type  of 
event  transactions  that  make  up  the  chain. 
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PROCESSING  TIMES 
REJECT  CHAIN  NETWORK  PATTERNS 
(Number  of  Days) 


Number 
Obs  • 

% 

Obs  • 

Chain  Network  Patterns 

Mean 

41,153 

77.5% 

RS-AR 

21.0 

1,961 

3.7 

RS-AR-FA- RF 

49.5 

4,090 

7.7 

RS-AR-RS-AA 

75.4 

259 

0.5 

RS -AR-R£ -FA-RS 

77.5 

249 

0.5 

RS-AR-FA-RF-RS-AA 

79.5 

3,908 

7.4 

RS-AR-RS-AR 

80.8 

172 

0.3 

RS-AR-FA-RF-FA-RF 

96.7 

296 

0.6 

RS-AR-RS-AR-Etc . -RS-AA 

111.2 

42 

0.1 

RS-AR-FA-RF-FA-RF-RS-AA 

114.9 

707 

1.3 

RS -AR-RS -AI-AF 

116.4 

53,088 

100.0% 

Reject  Pattern  Total 

33.2 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-120 


(6)  Summary 

The  life  cycle  analysis  analyzed  the  SSR  System 
in  terms  of  the  different  types  of  networks  that  can  occur  and 
attempted  to  measure  the  time  to  complete  the  supply  support  pro¬ 
cess  in  terms  of  these  networks.  Accept,  offer,  followup  and 
reject  network  categories  were  developed  and  chain  patterns  were 
developed  and  analyzed  in  terms  of  the  network  categories.  The 
networks  were  developed  by  using  the  control  data  contained  in  SSRs 
to  chain  SSR  transactions  together  in  a  time  sequential  3sries . 

The  intent  was  to  order  the  transactions  as  they  occurred  in  time 
from  the  point  when  the  request  was  generated  and  to  relate  all 
subsequent  events  to  the  original  request  in  the  order  in  which 
they  were  generated  and  processed. 

The  control  data  is  oriented  to  the  time  in  which 
a  transaction  was  created.  However,  the  time  a  given  transaction 
was  created  or  submitted  does  not  necessarily  relate  to  the  time 
it  was  received  or  processed.  Some  of  the  transactions  are  pro¬ 
cessed  manually  after  creation  and  are  sent  by  mail  while  others 
are  processed  mechanically  and  sent  electrically.  This  causes 
some  transactions  created  later  in  time  to  be  received  and  pro¬ 
cessed  before  others  that  may  have  been  created  earlier  in  time. 

The  advice  transactions  contain  a  date  of  advice  that  is  essen¬ 
tially  a  transaction  date  of  the  date  of  creation  of  the  advice, 
but  the  advice  must  be  related  back  to  a  request  transaction 
through  the  use  of  the  date  of  request  of  the  original  transaction. 
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The  eying  of  Che  advice  to  the  original  transac¬ 
tion  using  date  of  request  may  create  a  chain  that  is  different 
than  the  way  the  events  actually  occurred  in  time.  Although  the 
date  of  request  is  needed  to  chain  transactions  together  for  the 
same  item  identifying  number,  a  transaction  date  and/or  receipt 
date  may  be  required  to  properly  place  transactions  in  their 
logical  order  for  both  the  purposes  of  generating  an  audit  trail 
for  operational  processing  of  transactions  or  management  use  in 
measuring  performance. 

Performance  is  affected  by  the  pattern  of  events 
that  occur  over  the  life  cycle  of  an  SSR.  The  network  analysis 
showed  the  more  complex  the  network  in  terms  of  the  number,  types, 
combination  and  timing  of  events  that  occur;  the  longer  it  takes 
to  complete  the  supply  support  cycle.  Figure  1-121  summarizes  the 
various  types  of  events  and  estimated  times  for  initiating  these 
events.  This  table  can  be  used  to  estimate  the  life  cycle  time 
of  the  SSR  process.  Performance  can  be  improved  through  reducing 
the  number,  controlling  the  order  of  occurrence,  and  reducing  the 
processing  time  for  events.  The  study  objectives  can  be  achieved 
through  this  approach. 


EVENT  PROCESSING  TIMES 
(Number  of  Days) 


Event 

Mean 

10%-ILE 

50Z-ILE 

90%-ILE 

Net  Request  Transfer 

13 

5 

15 

31 

Net  Advice  Transfer 

4 

0 

1 

6 

Net  Reply  Transfer 

3 

0 

2 

4 

Net  Followup  Transfer 

2 

0 

1 

2 

Net  Response  Transfer 

3 

0 

2 

4 

AUTODIN  Transfer 

1 

0 

1 

3 

Initial  Accept 

22 

7 

18 

33 

Initial  NSN  Accept 

24 

15 

23 

34 

Final  NSN  Accept 

55 

37 

54 

73 

Offer 

19 

5 

26 

39 

Reply 

49 

20 

40 

89 

Followup  (Submission  Date) 

57 

35 

70 

72 

Followup  (Receipt  Date) 

30 

2 

27 

59 

Response 

1 

0 

1 

5 

Re  Jec t 

17 

2 

12 

33 

Resubmit  Request 

_ 

46 

5 

27 

107 

Source:  DODSSR  Data  Collection 


Figure  1-121 
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7.  Commonality .  The  DODSSR  Data  Base  was  analyzed  to  deter¬ 
mine  the  extent  of  commonality  of  usage  of  control  data  elements 
and  Item  Identifiers.  Commonality  In  this  sense  refers  to  the 
recurrent  usage  of  all  or  part  of  the  control  data  elements  or 
the  repeated  requesting  of  support  by  the  same  or  different  actlv 
lty  for  the  same  Item  of  supply. 

a .  Control  Data  Elements 

The  provisioning  control  codes  (PCC)  were  reviewed  to 
determine  the  extent  of  usage  of  the  same  PCC  for  different  equip 
ments.  Listings  of  the  same  PCC  were  prepared  showing  PCC  usage. 
An  analysis  of  this  listing  showed  that  the  same  PCC  may  be  used 
for  different  equipments  by  the  same  activity  or  by  different 
activities.  This  was  true  for  both  provisioning  and  nonprovision 
ing  requirements  although  It  was  more  predominant  for  nonprovi¬ 
sioning.  In  reviewing  the  listing  generated  from  program  data 
cards,  it  was  noted  that  the  end  item  name  in  the  program  data 
card  could  not  be  accessed  mechanically  because  of  the  minor 
variances  in  the  spelling  of  the  end  item  name. 

Listings  were  produced  for  line  item  supply  support 
requests  as  well  as  for  program  data  cards.  An  analysis  of  these 
listings  indicated  that  there  was  a  wide  range  of  repetition  in 
the  use  of  PCC  and  item  serial  number  (ISN).  We  found  that  the 
same  PCC  and  ISN  was  being  used  by  the  same  and  different  activ¬ 
ities  for  the  same  NSN  or  part  number  on  either  the  same  day 
(DOR)  or  on  different  days.  Some  activities  were  generating  many 
requests  using  the  same  PCC  and  ISN  for  different  items  of  supply 
for  nonprovisioning  items  in  particular.  Some  of  these  requests 
were  being  sent  to  the  same  IMM  and  some  of  them  were  being  sent 
to  different  IMMs  on  both  the  same  and  different  dates  of  request 

The  control  data  in  the  SSR  is  intended  to  be  used  to 
identify  transactions  to  facilitate  processing  at  both  the  SICC 
and  the  IMM.  The  control  data  is  used  to  record  requests  in 
suspense  files  at  both  the  SICC  and  the  IMM  and  to  control  the 
processing  of  transactions.  The  SSR  Procedures  prescribe  that 
the  PCC  is  required  as  a  positive  control  feature  in  data  pro¬ 
cessing  and  to  ensure  that  data  exchanges  between  activities  may 
be  related  to  the  same  end  item.  The  provisioning  activity  is  to 
assign  a  PCC  to  a  single  provisioning  project  or  program  and  not 
use  the  same  code  to  identify  a  different  project  within  the 
contract  life  of  the  same  project  to  which  it  is  first  assigned. 
The  item  serial  number  is  used  for  sequential  line  item  control 
and  for  means  of  communication  control.  The  serial  number  must 
be  repeated  in  all  line  item  cards  for  the  same  item  for  the  same 
request  and  for  all  subsequent  actions  pertaining  to  the  original 
request.  The  DOR  is  required  to  be  repeated  in  any  SSR  transac¬ 
tions  that  relate  to  an  original  request. 
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When  duplicate  control  data  is  used  by  the  same  activ¬ 
ity  on  the  same  day,  the  transactions  are  subject  to  being  re¬ 
jected  as  duplicates  by  the  IMM  if  they  are  received  and  processed 
during  the  same  cycle.  If  the  same  control  data  is  used  for  the 
same  item,  advice  received  by  a  S1CC  from  an  IMM  may  be  recorded 
against  the  wrong  record  in  the  suspense  files  of  the  SICC.  The 
SICC  may  then  followup  on  an  item  for  which  support  advice  hae 
been  sent  out  and  receive  advice  for  another  item  with  the  same 
control  data  and  log  this  advice  against  the  same  or  a  different 
transaction.  The  records  for  both  the  SICC  and  IMM  may  now  con¬ 
tain  entries  on  transactions  in  their  suspense  files  that  were 
intended  for  other  requests. 

The  previous  analysis  of  reject  and  followup  chains 
with  multiple  repeating  transactions  tend  to  confirm  that  the 
misapplication  of  control  data  can  lead  to  the  incorrect  relation¬ 
ship  request  and  advice  transactions  containing  the  same  control 
data  but  with  different  identification  data. 

The  SSR  Procedures  should  be  revised  to  more  clearly 
specify  the  entry  and  use  of  all  control  data  to  indicate  that 
the  same  control  data  PCC  and  ISN  should  not  be  used  for  different 
items  for  the  duration  of  existence  of  the  PCC.  The  date  of  re¬ 
quest  should  be  established  as  the  initial  generation  of  a  request 
for  an  item  of  supply  (ISN)  for  a  PCC.  All  subsequent  transac¬ 
tions  using  the  same  PCC  and  ISN  from  the  same  activity  should  be 
designated  as  transactions  providing  changes  to  the  original  re¬ 
quest  or  Information  on  the  original  request  or  subsequent  changes 
A  transaction  date  should  be  assigned  to  each  transaction  that  is 
created  so  that  subsequent  transactions  for  the  same  item  of 
supply  for  the  same  activity  may  be  related  to  each  other  in  the 
audit  trails  of  both  the  SICC  and  the  IMM. 

The  systems  of  the  S^CCs  should  then  be  designed  to  be 
compatible  with  the  revised  SSR  Procedures.  A  check  for  dupli¬ 
cate  control  data  for  the  same  or  different  items  of  supply 
should  be  included.  Duplicates  should  either  be  edited  by  the 
system  or  rejected  as  validation  errors  for  correction  prior  to 
submission  to  the  IMM.  Requests  for  the  same  item  of  supply  for 
the  same  PCC  with  different  ISNs  being  processed  during  the  same 
cycle  should  be  rolled  up  Into  one  request  with  the  same  control 
data.  The  suspense  file  should  be  accessed  to  ensure  that  new 
requests  being  processed  do  not  use  the  same  ISN  for  different 
items  of  supply  for  the  same  PCC.  If  the  same  item  of  supply  is 
being  requested  under  the  same  PCC,  the  request  should  be  pro¬ 
cessed  as  a  change  or  augmentation  of  the  original  request. 
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Item  Identifiers 


Item  identifier  as  used  in  this  context  means  the 
stock  number,  part  number  or  permanent  system  control  number  used 
to  identify  an  item  of  supply  on  a  supply  support  request.  Re¬ 
ports  were  generated  to  determine  the  incidence  of  appearance  of 
the  same  item  identifier  for  different  activities.  Figure  1-122 
shows  the  incidence  of  commonality  of  requests  for  stock  numbered 
i terns . 


CXA  COMMONALITY  REPORT 


Number 

Activities 

Number 

I  terns 

Total 

Number 

Items 

%  Total 
Numbe  r 
Items 

Total 

Number 

Records 

1 

66,708 

90.4 

2 

5,668 

7.7 

3 

959 

1.3 

4 

277 

0.4 

5 

105 

0.1 

6 

43 

0.1 

7 

15 

8 

4 

9 

1 

10 

73,780 

131,867 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-122 

The  table  indicates  that  almost  10%  of  the  stock  num¬ 
bers  contained  in  supply  support  requests  were  common  to  two  or 
more  submitting  activities.  There  were  7.7%  common  to  two  activ¬ 
ities  and  1.9%  were  common  to  three  or  more  activities.  The  ratio 
of  the  total  number  of  records  to  the  total  number  of  items  indi¬ 
cates  that  there  is  a  significant  amount  of  commonality  of  SSRs 
for  the  same  item  from  the  same  activity.  It  can  not  be  said 
with  statistical  certainty  what  the  exact  amount  of  within  activ¬ 
ity  commonality  is  because  of  the  incidence  of  duplication  of 
control  data  elements  due  to  the  resubmission  of  requests  that 
had  been  rejected  and  the  regeneration  of  requests  based  upon  the 
receipt  of  a  No  Record  response  to  a  followup  for  advice. 

The  table  in  Figure  1-123  provides  the  incidence  of 
commonality  for  part  numbered  requests. 
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CXB  COMMONALITY  REPORT 


Total 

%  Total 

Total 

Number 

Number 

Number 

Number 

Number 

Activities 

Items 

Items 

Items 

Records 

1 

91,381 

98.3 

2 

1,488 

1.6 

3 

93 

0.1 

4 

5 

5 

4 

6 

7 

8 

9 

10 

_  _ 

92,971 

117,649 

Source:  DODSSR  Data  Collection;  Main  Population 


Figure  1-123 

There  were  1.7%  of  the  items  with  part  numbers  that 
were  common  to  two  or  more  activities.  The  ratio  of  the  gross 
and  net  records  for  part  numbered  items  also  indicates  an  inci¬ 
dence  of  commonality  of  requests  within  activity  as  well  as  among 
activities.  A  good  estimate  of  the  within  activity  commonality 
for  part  numbered  items  could  not  be  determined  because  of  the 
resubmission  situation  described  for  stock  numbered  items  above. 

The  incidence  of  commonality  is  discussed  because  of 
the  continuing  complaints  received  from  SICCs  that  too  many  items 
were  being  classified  as  centrally  procured  and  not  stocked.  Cur¬ 
rently  the  decision  to  stock  a  part  numbered  item  or  to  change 
the  stockage  decision  on  an  existing  item  are  made  based  upon  the 
consideration  of  individual  requests.  The  SICCs  feel  that  these 
items  will  experience  demand  and  that  it  takes  too  long  to  con¬ 
vert  an  item  from  centrally  procured  to  stocked  on  the  basis  of 
subsequent  demand  from  requisitions.  The  SICCs  recommend  that 
the  IMMs  accumulate  demand  contained  in  the  SSRs  over  time  and 
change  the  management  decision  to  centrally  stocked  if  the  accu¬ 
mulated  demand  warrants  it • 

The  incidence  of  duplication  of  control  numbers  for 
the  sane  Items  and  occurrence  of  SSRs  with  the  same  PCC  with  dif¬ 
ferent  item  serial  numbers  for  the  same  item  on  the  same  day  or 
in  the  same  cycle  Indicates  that  the  SICCs  are  not  attempting  to 
roll  up  demand  for  the  same  item  across  PCCs  or  even  within  the 
same  PCC. 
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Some  consideration  should  be  given  to  the  rolling  up 

of  demand  by  the  SICC  prior  to  submitting  the  SSR  and  by  the  IMM 

in  rolling  up  demands  for  the  same  item  in  the  same  processing 
cycle  and  accumulating  demands  in  SSRs  over  a  forecast  period. 

It  would  appear  that  the  SICC  should  consider  repetitiveness  of 
demand  for  items  within  the  same  PCC  for  the  same  activity.  The 

IMM  should  consider  demands  for  the  same  item  for  different  PCCs 

for  the  same  activity  and  demands  for  the  same  item  for  different 
activities . 

The  DOOSSR  Study  did  not  attempt  to  quantify  the 
potential  for  rolling  up  or  accumulating  demand  because  the  re¬ 
quirements  determination  processes  for  computing  the  range  and 
depth  of  item  requirements  are  outside  the  scope  of  the  study. 

An  extract  could  be  made  of  SSR  suspense  files  by  SICCs  and  IMMs 
over  a  forecast  period.  The  selected  SSRs  could  then  be  processed 
through  the  programs  currently  used  to  compute  range  and  depth 
requirements.  The  SSRs  could  be  first  processed  through  indi¬ 
vidually  as  is  the  case  today.  The  selected  SSRs  could  then  be 
rolled  up  and  the  summed  quantities  processed  through  the  com¬ 
putation  programs  to  determine  the  number  and  percent  of  items 
that  would  be  stocked  if  the  demand  were  accumulated.  This  pro¬ 
cess  could  be  accomplished  using  the  existing  computation  pro¬ 
grams  in  the  test  mode  without  affecting  existing  records  for 
active  items  and  without  extensive  reprogramming.  The  results  of 
the  test  would  then  form  the  basis  for  determining  whether  accu¬ 
mulation  or  rollup  of  SSR  demand  should  be  performed  by  the  SICC 
or  the  IMM  on  a  continuing  basis. 

8.  Management/Technical  Data  Element  Usage.  Management  data 
elements  are  used  to  convey  or  perform  decisions  relating  to 
source,  method  and  level  of  support  of  items  in  the  supply  system. 
Technical  data  elements  are  used  to  convey  or  perform  decisions 
relating  to  item  identification,  item  entry  control  and  catalog¬ 
ing  of  items  of  supply.  Submitters  of  SSRs  include  these  data 
elements  in  the  SSR  to  reflect  determinations  made  by  the  end 
item  contractor  which  are  included  in  the  provisioning  list,  and 
to  provide  recommendations  to  the  prospective  IMM  based  upon 
determinations  made  by  the  submitter  as  the  provisioning  activ¬ 
ity.  The  study  team  received  information  during  field  research 
visits  and  from  answers  to  questionnaires  indicating  that  the 
Interpretation,  application  and  usage  of  certain  data  elements 
among  submitters  and  receivers  of  SSRs  was  quite  variable.  Based 
upon  this  information  a  series  of  reports  were  generated  from  the 
DODSSR  Data  Base  to  analyze  the  relative  usage  and  utility  of 
these  data  elements  and  compare  this  analysis  with  other  study 
research . 
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a.  PB  Source  Code  Usage 

Source  codes  are  part  of  the  Source,  Maintenance  and 
Recoverability  Codes  (SM&R)  prescribed  by  a  joint  regulation  gov¬ 
erning  the  use  of  these  codes  (Appendix  D,  Reference  20).  Source 
codes  are  assigned  to  support  items  to  indicate  the  manner  of 
acquiring  items  for  the  maintenance,  repair  or  overhaul  of  end 
items.  A  Source  Code  PB  item  is  defined  as  an  “Item  procured  and 
stocked  for  insurance  purposes  because  essentiality  dictates  that 
a  minimum  quantity  be  available  in  the  supply  system.”  The  in¬ 
structions  for  preparing  SSRs  in  Appendix  E  of  the  1MM  Manual 
prescribe  the  entry  of  ”P”  series  source  codes  in  SSRs,  except 
for  active  stock  numbered  items. 

The  Defense  Logistics  Agency  (DLA)  performs  an  edit/ 
validation  on  the  source  code.  The  designation  of  an  item  as 
Source  Code  PB  is  then  given  consideration  in  method  and  level  of 
support  determinations  to  determine  if  the  item  should  be  stocked 
as  an  Insurance  item. 

Figure  1-124  shows  the  frequency  of  usage  of  PB 
Source  Codes  in  part  number  SSRs.  Although  the  average  total 
usage  of  2.  IT  does  not  appear  to  be  unreasonable,  there  is  a  vide 
variation  in  usage  among  submitters  of  SSRs.  There  is  no  stan¬ 
dard  establishing  the  number  or  percentage  of  items  that  should 
be  classified  as  insurance  type  items.  However,  the  total  absence 
of  usage  by  some  activities  as  compared  with  the  nine  to  ten  per¬ 
cent  rate  by  ASO  and  SPCC  Indicates  a  lack  of  understanding  of 
the  application  and  use  of  this  data  element. 

The  SSR  Procedures  specify  the  entry  of  only  P  Series 
Source  Codes  as  a  mandatory  entry  for  new  items.  The  procedures 
do  not  indicate  to  the  submitter  the  expected  result  of  the  entry 
of  this  data  element,  nor  do  the  procedures  prescribe  usage  of 
this  data  element  by  the  SSR  receiver.  This  data  element  is  some¬ 
what  related  to  the  Acquisition  Advice  Code  (AAC)  whose  usage  is 
shown  on  the  next  figure;  however,  the  PB  Source  Code  is  the  only 
current  vehicle  in  the  SSR  for  establishment  of  an  item  as  an 
insurance  item  that  is  used  by  an  IMM. 

The  wide  variation  in  the  application  and  usage  of 
Source  Code  PB  indicates  that  the  utility  of  this  code  should  be 
reviewed  to  determine  if  it  should  continue  to  be  used,  replaced 
or  combined  with  another  data  element.  If  the  data  element  is  to 
continue  to  be  used,  more  specific  procedures  and  criteria  for 
i 1 8  entry  by  submitters,  and  use  by  receivers  should  be  specified 
in  the  SSR  Procedures.  This  is  necessary  to  ensure  uniform  pro¬ 
cedures  and  criteria  for  the  selection,  recommendation  and  designa¬ 
tion  of  insurarce  items  to  support  critical  end  item  equipment 
applications . 
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PB  SOURCE  CODE  USAGE 
(Frequency  of  Occurrence) 


■EEHK339 

No.  PB 

Row  % 

Column  % 

Activity 

RH 

Source  Codes 

PBs 

PBs 

ARRCOM 

Ha 

w 

mm 

0.0% 

CERCOM 

28 

mBBmi 

1.0 

MIRCOM 

— 

0.0 

TARCOM 

41 

wmsm 

1.5 

TSARCOM 

■non 

289 

10.2 

10.7 

Army 

mmm 

358 

3.9% 

13.2% 

ASO 

22,120 

.  _ 

o.ox 

0.0% 

SPCC 

22,405 

2,050 

75.7 

Navy 

44,525 

2,050 

4.6% 

75.7% 

OCALC 
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Figure  1-124 

b .  Acquisition  Advice  Code  (AAC)  Usage 

Paragraph  4-2b  of  the  SSR  Procedures  advises  submit¬ 
ters  of  SSRs  to  recommend  to  the  CIMM  the  assignment  of  AAC  J 
(Centrally  Procured-Not  Stocked)  for  those  Items  with  low  pre¬ 
dicted  demands  that  are  known  to  be  commercially  available  and 
are  not  required  for  system  support  of  high  priority  weapon  sys¬ 
tems*  Paragraph  E-4c  of  Appendix  E  of  the  SSR  Procedures  pre¬ 
scribes  the  use  of  AAC  J  to  obtain  an  NSN  assignment  and/or  cata¬ 
log  registration  for  CIMM  items  for  maintenance  significent  items 
for  which  demand  is  unknown  or  criteria  indicates  items  are  not 


appropriate  for  initial  stocking  in  the  CIMMs  supply  system, 
provided  a  retail  quantity  has  been  procured  by  the  submitter  of 
the  SSR,  and  zeros  are  entered  in  the  replenishment  and  retail 
quantity  fields.  There  is  an  associated  Action  Taken  Code  (ATC) 
used  in  advice  cards  by  the  CIMM  to  reject  requests  that  contain 
an  AAC  J  with  quantities  greater  than  zero  in  the  quantity  fields. 

The  procedures  in  paragraph  E-4e  of  Appendix  E  con¬ 
taining  instructions  for  preparing  a  request  for  an  active  NSN 
item  specifies  AAC  as  an  optional  entry.  The  requestor  may  re¬ 
commend  a  method  of  management  which  will  result  in  stockage  when 
submitting  requirements  for  a  nonstocked  item;  otherwise,  the 
field  is  to  be  blanked.  The  SSR  Procedures  in  the  Appendix  for 
preparation  of  a  request  for  an  inactive  NSN,  part  number  or  per¬ 
manent  system  control  number  item  specify  the  entry  of  AAC  J  if 
the  quantity  fields  are  zero,  otherwise  the  AAC  field  is  to  be 
blanked . 

Based  upon  the  information  received  during  field 
research  and  a  review  of  the  procedures  as  outlined  above,  a  fre¬ 
quency  distribution  of  the  use  of  AACs  was  generated  from  the 
DODSSR  Data  Base.  Figure  1-125  depicts  this  distribution.  The 
various  AACs  were  summarized  into  appropriate  categories  to  show 
the  AAC  recommendations  of  the  submitters  for  new  items.  Stock 
numbered  requests  were  not  reviewed,  since  the  study  team  had  no 
way  of  determining  whether  an  item  was  already  stocked  or  not; 
and  the  procedures  specify  the  entry  of  an  AAC  only  when  the  sub¬ 
mitter  1 8  recommending  stockage  for  an  item  with  a  stock  number 
that  is  not  stocked. 

The  relationship  of  categories  in  the  Figure  to  actual 
AACs  is  shown  below: 

(1)  No  Recommendation  -  Blank  or  Numeric  0. 

(2)  Central  Stock  -  AACD  or  G,  stocked  by  DoD  or  GSA. 

(3)  Central  Procure  -  AAC  J  with  replenishment  or 
retail  quantity  greater  than  zero. 

(4)  NSN  Assignment/Regis tration  -  AAC  J  with  zeros 
in  both  quantity  fields. 

(5)  Other  -  Reflects  codes  other  than  those  above 
that  are  valid  codes  but  they  are  inappropriate  as  a  recommenda¬ 
tion  to  a  CIMM  or  the  codes  are  invalid. 


The  distribution  shows  that  80%  of  the  time  no  AAC 
recommendation  is  made.  The  twenty  percent  of  the  time  that  an 
AAC  is  recommended  is  broken  down  as  follows: 

*  Central  Stock  .  16. 6% 

*  Central  Procure  with  demand  ...  0.3% 

*  NSN  Assignment/Registration  ...  82.8% 

*  Other  . .  0.3% 

However,  if  the  Navy's  central  stock  recommendation 
is  eliminated  it  shows  that  over  99%  of  the  time  when  the  AAC  J 
Code  is  used  it  is  used  according  to  the  procedures  in  Appendix  E 
to  the  SSR  procedures.  But  it  is  difficult  to  believe  that  16.5% 
of  all  SSRs  for  new  items  represent  a  cataloging  request  only, 
without  a  request  for  quantitative  support.  Moreover,  the  indi¬ 
vidual  service  percentages  for  the  Army-  27.6%,  Air  Force-  23.2% 
and  Marine  Corps-  54%  of  Service  totals  seem  a  rather  high  propor¬ 
tion  of  SSRs  with  a  zero  requirement  with  retail  stock  purchased 
by  the  requesting  activity.  The  small  number  of  AAC  J  recommen¬ 
dations  with  a  requirement,  84  for  .06%  of  all  new  SSRs  submitted 
seems  very  low  when  reminded  that  the  Services  were  requested  to 
recommend  central  procurement  and  no  stockage  for  items  with  low 
as  opposed  to  no  demand. 

A  review  of  these  statistics  in  Figure  1-125  coupled 
with  the  conflicting  instructions  in  the  SSR  Procedures  and  in¬ 
formation  from  field  research  review  indicates  a  lack  of  under¬ 
standing  of  the  intent,  purpose  and  usage  of  AACs  by  submitters 
and  receivers  of  SSRs. 

Since  there  was  such  a  low  usage  of  Source  Code  PB 
(Insurance  Item)  by  SSR  Submitters,  we  looked  to  see  how  many 
times  AAC  Z  ( Insurance /Numeric  Stockage  Objective  Item)  was  being 
used.  We  found  that  it  was  being  used  only  0.007%  of  the  time 
for  all  new  items  being  requested. 

It  is  concluded  that  current  procedures  and  usage  of 
the  AAC  are  conflicting,  varied  and  vague.  This  code  should 
either  be  deleted,  combined  with  another  code,  or  definitive  pro¬ 
cedures  and  criteria  for  its  entry  by  submitters  and  processing 
by  receivers  should  be  provided. 

c .  Procurement  Method  Code  (PMC) 

The  procedures  in  Appendix  E  of  the  SSR  Procedures 
specify  that  the  PMC  will  be  entered  in  SSRs  for  other  than  active 
NSN  items.  The  definition  provides  for  the  entry  of  a  one  char¬ 
acter  numeric  code  as  a  mandatory  SSR  data  element.  However,  the 
format  exhibits  provide  that  the  entry  is  optional  for  WIMM 
items.  The  codes  are  contained  in  Volume  10,  Chapter  4,  Table  71 
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The  procedures  do  not  provide  for  the  entry  of  the 
suffix  code  of  the  PMC.  Activities  submitting  SSRs  reported  that 
the  code  was  useless  without  the  suffix  code,  that  the  code  was 
not  meaningful  any  way  because  the  information  was  not  available 
at  the  time  of  provisioning,  and  that  the  code  should  be  assigned 
by  the  IMM. 


The  statistics  in  the  figure  show  that  over  70%  of 
the  part  number  SSRs  sent  to  CIMMs  were  zero  or  blank  in  the  PMC 
field  indicating  that  the  items  had  not  been  screened  for  procure¬ 
ment  method  or  that  a  blank  was  entered  and  no  recommendation  was 
made.  Competitive  procurement  was  generally  recommended  as  the 
procurement  method  when  a  recommendation  was  provided.  The  in¬ 
formation  in  the  PMC  overlaps  information  provided  by  the  Docu¬ 
ment  Availability  Code  (DAC),  Reference  Number  Category  Code  (RNCC) 
and  the  Reference  Number  Variation  Code  (RNVC). 

Based  upon  the  relative  low  entry  of  meaningful 
codes,  this  data  element  should  be  considered  for  deletion  with 
information  provided  in  the  DAC,  RNCC,  RNVC  used  as  a  substitute. 

d .  Document  Availability  Code  ( DAC) /Technical  Data 
Justification  Code  (TDJC) 


The  DAC  is  a  one  digit  numeric  code  that  Indicates 
the  status  of  availability  of  technical  data  to  the  Reference 
Number  Action  Activity  Code  (RNAAC).  The  SSR  Procedures  specify 
the  conditional  entry  of  this  data  element  in  the  CXB  Card  No.  2 
for  CIMM  items  when  technical  data  is  not  provided  with  the  SSR. 
The  code  is  not  required  when  technical  data  is  provided  to  the 
CIMM.  The  codes  are  listed  in  Volume  10,  Chapter  4,  Table  5,  DoD 
4100. 39M,  DIDS  Procedures  Manual  (Appendix  D,  Reference  25). 

The  TDJC  is  a  one  character  alphabetic  code  to  indi¬ 
cate  a  specific  reason  for  not  furnishing  technical  data  for  part 
number  SSRs  submitted  to  a  CIMM  without  technical  data.  The  SSR 
Procedures  specify  the  conditional  entry  of  this  data  element  in 
CXB  Card  No.  2  when  technical  data  is  not  available.  Entry  is 
not  required  If  technical  data  is  forwarded  with  the  SSR  or  if 
the  Date  Technical  Data  to  be  Supplied  is  provided. 

Figure  1-127  shows  the  availability  of  technical 
data  as  entered  in  CXB  Card  No.  2  items  generated  from  the  DODSSR 
Data  Base.  The  usage  of  both  codes  is  shown  on  the  same  figure 
due  to  the  degree  of  overlap  of  the  two  data  elements.  There 
appears  to  be  the  same  inconsistency  in  the  use  of  these  codes  as 
for  the  other  data  elements  discussed  above. 
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Although  the  DAC  Is  not  to  be  entered  when  technical 
data  Is  supplied  with  the  SSR  the  Army  entered  DACs  indicating 
that  technical  data  was  available  45.2%  and  the  Navy  37.9%  of  the 
time.  TSARCOM  entered  a  DAC  indicating  that  technical  data  was 
not  available  46.7%  of  the  time  while  entering  TDJCs  indicating 
that  technical  data  was  not  available  26.3%  of  the  time. 

The  Navy  was  quite  consistent  in  the  application  of 
DACs  and  TDJCs.  DAC  was  entered  over  99%  of  the  time  indicating 
that  technical  data  was  not  supplied  with  the  SSR  while  both  DAC 
and  TDJC  entries  indicate  that  technical  data  was  available  over 
37%  of  the  time. 

The  Air  Force  like  the  Navy  almost  always  entered  a 
DAC ,  with  almost  100%  entry  of  DACs  indicating  technical  data  was 
not  available.  But,  TDJC  entries  indicated  that  data  was  not 
available  only  18.5%  of  the  time  for  total  Air  Force  and  43.9%  of 
the  time  it  was  not  available  for  WRALC.  The  total  availability 
figures  for  all  Components  reflect  the  same  degree  of  variability 
in  the  application  of  these  codes. 

The  DAC  is  a  required  data  element  for  entry  into 
DIDS  files.  It  is  used  in  combination  with  the  Reference  Number 
Category  Code  (RNCC)  and  the  Reference  Number  Variation  Code 
( RNVC )  both  of  which  are  contained  in  the  SSR.  The  TDJC  should 
be  considered  for  elimination  and  the  DAC  should  be  used  instead. 
Procedures  for  entry  of  the  DAC  should  then  be  clarified  to 
clearly  spell  out  the  conditions  for  entry  of  information  rela¬ 
tive  to  the  availability  of  technical  data. 

e.  Weapon  System  Code  (WSC) .  The  WSC  is  the  two  digit 
numeric  portion  of  codes  assigned  to  selected  weapon  systems  under 
Enclosure  1  of  DLAR  4140.38  (Appendix  D,  Reference  28).  The  code 
is  entered  In  the  Program  Data  Card  when  the  SSR  submitter  desires 
to  advise  the  IMM,  otherwise  the  field  is  to  be  left  blank.  Fig¬ 
ure  1-128  was  prepared  based  upon  the  program  data  cards  received 
in  the  DODSSR  Data  Collection.  Valid  conditions  are  blank  or  a 
code  listed  on  Enclosure  1  to  the  DLA  regulation. 


WEAPON  SYSTEM  CODE  USAGE 


Total 


Source : 


Figure  1-128 
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There  were  a  total  of  76  different  code  entries  in 
the  Program  Data  Supply  Support  Requests  (PDSSRs)  received;  blank 
or  the  absence  of  advice,  12  valid  code  entries  from  the  regula¬ 
tion  and  63  Invalid  codes  that  were  not  listed  In  the  regulation. 
Blanks  appeared  92. 6%  of  the  time  with  valid  codes  appearing  only 
2.6%  of  the  time.  Considering  codes  other  than  blank,  that  Is, 
when  an  advice  Is  actually  being  provided,  valid  codes  were  pro¬ 
vided  32%  of  the  time,  while  invalid  codes  were  provided  68%  of 
the  time. 


The  S SR  Procedures  do  not  Indicate  to  the  submitter 
the  reason  for  entering  the  code  or  to  the  receiver,  what  to  do 
with  the  code  when  received.  A  review  of  current  practices  Indi¬ 
cates  that  the  code  Is  not  being  used  and  serves  no  useful  pur¬ 
pose.  A  DLA  letter  of  18  May  1977  concerning  policy  for  provi¬ 
sioning  of  selected  weapon  systems  (Appendix  D,  Reference  29), 
refers  to  the  DLA  Weapon  System  Regulation  and  outlines  a  proce¬ 
dure  for  the  Military  Services  to  nominate  selected  weapon  systems 
to  be  covered  by  the  provisions  of  the  Weapon  System  Letter.  The 
nominations  are  to  be  identified  by  Provisioning  Control  Code 
(PCC)  not  WSC.  After  approval  by  DLA,  the  SSR  submitter  is  ad¬ 
vised  to  use  the  PCC  in  the  SSR  and  the  Defense  Supply  Center  is 
to  recognize  the  PCC  in  combination  with  the  submitting  activity 
code  when  processing  the  SSR. 

A  special  letter  of  transmittal  is  supposed  to  accom¬ 
pany  those  SSRs  using  this  procedure,  to  ensure  special  stockage 
treatment  for  items  in  selected  weapons  systems.  The  special 
stockage  consideration  provides  for  stockage  of  items  identified 
as  weapon  system  items  that  would  not  normally  qualify  for  stock- 
age  under  the  stockage  criteria  published  in  DoDI  4140.42  (Appen¬ 
dix  D,  Reference  10). 

The  Weapon  System  Letter  applies  to  initial  stockage 
of  items  in  weapon  systems  that  have  been  nominated  and  approved 
in  accordance  with  the  procedures  contained  in  the  letter.  The 
Weapon  System  Regulation  provides  for  follow-on  replenishment  and 
stockage  of  spec  *  * '  ~  ^dividual  items  in  weapon  systems  that  have 
been  nominated  ..d  approved  in  accordance  with  the  procedures 
contained  in  he  regulation.  Although  the  letter  seems  to  con¬ 
sider  all  lte,is  in  an  approved  weapon  system  for  special  treat¬ 
ment,  the  regulation  deals  with  individual  items  within  a  weapon 
system.  It  is  unclear  whether  the  population  of  approved  weapon 
systems  in  the  regulation  is  equal  to,  greater  than,  or  less  than, 
the  population  of  approved  weapon  systems  in  the  letter. 

The  WSC  as  currently  entered  into  the  SSR  has  no  real 
meaning  or  usage,  since  the  PCC  is  being  used  in  the  SSR  to  iden¬ 
tify  items  as  essential  to  weapon  systems  for  priority  processing 
and  initial  stockage  considerations.  Based  upon  our  review  of 
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the  PB  Source  Code,  the  AAC ,  and  the  WSC,  the  use  of  all  three  of 
these  codes  in  the  SSR  la  questionable*  Since  none  of  these  codes 
appear  to  have  any  real  utility  for  designating  essentiality , 
method  of  support,  level  of  support  and  priority  processing,  an¬ 
other  method  or  method(a)  should  be  considered. 


9 .  Nonconsumable  Item  Materiel  Support  Requests  (NIMSRs) 

The  statistical  data  presented  for  NIMSRs  was  obtained 
from  the  DODSSR  Data  Base.  The  data  base  for  NIMSRs  was  in 
manual  form,  since  data  collected  for  NIMSRs  consisted  of  copies 
of  manual  NIMSRs  prepared  in  accordance  with  the  joint  regulation 
governing  the  management  of  nonconsumable  items  (Appendix  D,  Ref¬ 
erence  21).  The  information  shown  in  the  tables  below  was  ob¬ 
tained  by  summarizing  the  data  contained  in  the  copies  of  the 
forms  received. 

Each  submitter  (SICA)  of  a  NIMSR  or  receiver  (PICA)  was 
requested  to  submit  copies  of  all  NIMSR  forms  generated  or  re¬ 
ceived  during  the  data  collection  period.  A  sample  copy  of  a 
NIMSR  Form  is  contained  in  Figure  1-129.  The  NIMSR  is  a  two  part 
form  containing  information  to  be  filled  in  by  the  requestor  and 
the  receiver.  The  requesting  service  fills  out  blocks  1-18  and 
the  PICA  completes  blocks  19-28.  The  remarks  block  may  be  used 
by  either  the  PICA  or  the  SICA. 

Submitters  of  NIMSRs  were  requested  to  annotate  the  date 
NIMSRs  were  forwarded  to  the  PICA  and  to  indicate  the  date  re¬ 
ceived  on  copies  of  completed  NIMSRs  received  from  the  PICA. 

PICAs  were  requested  to  annotate  the  date  NIMSRs  were  received 
from  the  SICA  and  the  date  of  submission  of  completed  forms  to 
the  SICA  indicating  the  advice  of  action  taken  on  the  request  for 
support.  It  was,  therefore,  possible  for  the  study  group  to 
receive  four  copies  of  a  NIMSR  from  the  same  submitting  and  re¬ 
ceiving  activities  for  the  same  item.  These  copies  were  matched 
together  using  the  activity  codes,  date  of  request  and  the  item 
identifying  number  (NSN  or  part  number).  Because  of  the  beginning 
and  ending  cutoff  dates,  four  copies  were  not  received  for  each 
request.  The  data  base  may  contain  1,  2 ,  3  or  4  copies  of  a  for 
for  the  same  request  for  the  same  item.  Net  counts  were  obtaine 
by  matching  all  copies  for  the  same  request  together. 

a.  Volumes 


Figure  1-130  shows  the  number  of  different  requests 
submitted  or  received  during  the  eight  month  data  collection 
period.  The  total  of  2,890  represents  the  net  count  of  different 
requests.  Counts  are  displayed  by  DIDS  Activity  Codes  to  show 
the  relationships  between  submitters  and  receivers  of  NIMSRs. 
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The  largest  submitter /receiver  relationships  were 
among  SMALC  (TA),  SPCC  (HD)  and  CERCOM  (CL).  SMALC  sent  82%  of 
Its  outgoing  traffic  to  CERCOM,  while  SPCC  sent  44%  of  its  out¬ 
going  traffic  to  CERCOM.  CERCOM  was  the  largest  single  receiver 
of  NIMSRs,  receiving  56. 2Z  of  its  traffic  from  SMALC  and  25. 6%  of 
1 1 8  traffic  from  SPCC. 

The  information  in  Figure  1-131  summarizes  the  leading 
submitters  and  receivers  of  NIMSRs.  The  Aviation  Supply  Office 
(KE)  was  the  leading  submitter  and  the  Communications  Electronics 
Readiness  Command  was  the  largest  receiver.  Note  that  three  actlv 
ltles  account  for  the  majority  of  submissions  and  three  activities 
account  for  the  majority  of  the  receipts. 

LARGEST  NIMSR  ACTIVITY  SUBMITTERS/RECEIVERS 
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Figure  1-131 

Submitter/Receiver  relationships  are  summarized  by 
service  in  Figure  1-132.  The  Navy  is  the  largest  service  submit¬ 
ter  while  the  Army  is  the  largest  service  receiver.  However,  the 
Air  Force  participates  about  equally  as  a  submitter  and  receiver. 

NIMSR  SERVICE/RECEIVER  (PERCENT)  RELATIONSHIP 
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Source:  DODSSR  Data  Collection 


Figure  1-132 
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b.  Completion  Times 

Copies  of  NIMSRs  were  collected  each  time  a  form  was 
sent  between  submitters  and  receivers  of  NIMSRs  with  the  date  of 
the  action  being  recorded  on  the  NIMSR  to  permit  computation  of 
completion  times  for  the  various  NIMSR  processing  time  segments. 
Three  types  of  times  were  computed  as  defined  below: 
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(2)  PICA  Processing  Time.  This  time  was  computed  by 
subtracting  the  date  the  PICA  received  the  request  from  the  date 
the  PICA  completed  processing  on  the  request. 

( 3 )  Internal  Wait  Times 
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Figure  1-133  shows  times  required  to  complete  pro¬ 
cessing  of  NIMSRs.  The  data  is  arrayed  by  the  submitting  ser¬ 
vice.  There  are  three  major  processing  phases  shown;  SICC  Sub¬ 
mission,  PICA  Processing  and  PICA  Submission.  Submission  times 
are  broken  down  into  wait  time  and  transmission  time.  The  time 
segments  shown  represent  the  major  phases  in  the  generation, 
transmission  and  processing  of  a  NIMSR.  The  time  for  a  NIMSR 
starts  from  the  date  of  request  on  the  NIMSR  form  and  is  completed 
when  completion  advice  is  received  by  the  submitting  activity. 


The  time  segments  are  depicted  in  their  chronological 
order  reading  from  left  to  right  on  the  figure.  Each  of  the  seg¬ 
ments  represents  an  average  time  for  accomplishment  of  the  par¬ 
ticular  phase  or  event.  The  average  times  were  then  summed  to 
obtain  an  average  total  completion  time  for  a  NIMSR.  The  number 
of  transactions  used  to  compute  each  time  segment  average  varied 
based  upon  the  number  of  copies  received  in  the  data  collection 
from  the  SICAs  and  PICAs  representing  the  dates  they  submitted  or 
received  NIMSR  documents. 
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NIMSR  COMPLETION  TIMES 
(Average  Number  of  Days  by  Submitter) 


SICA  Submission 

i  PICA  | 

PICA  Sul 

smission 

Service 

Internal 

Halt 

Trans¬ 

mission 

Internal 1 
Wait 

Trans- 

Mission 

Average 

Total 

Army 

30.4 

— 

33.2 

23.0 

112.6 

Navy 

26.3 

1 

42.6 

20.0 

101.6 

Air  Force 

16.1 

22.7 

16.6 

63.3 

MC 

5.9 

■09 

15.6 

0.1 

5.9 

45.2 

Average 

Total 

19.8 

■ 

20.5 

36.3 

1.1 

9.5 

87.2 

Source:  DODSSR  Data  Collection 


Figure  1-133 

Note  that  there  is  a  large  variance  among  the  times 
for  the  individual  segments  as  well  as  the  average  total  times  by 
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NIMSR  COMPLETION  TIMES 
(Average  Number  of  Days  by  Receiver) 
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Figure  1-134 
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The  pie  chart  in  Figure  1-135  pictorally  shows  the 
proportion  of  time  required  for  each  of  the  time  segments.  Al¬ 
though  PICA  processing  time  is  the  largest  segment  as  would  be 
expected,  the  times  for  wait  and  transmission  seem  inordinately 
high,  particularly  for  SICA  processing.  The  SICA  times  are 
attributed  to  the  general  tendency  to  batch  actions  into  packages 
during  the  provisioning  process.  The  use  of  larger  packages  of 
outgoing  NIMSRs  would  probably  tend  to  slow  down  mail  time  due  to 
the  size  of  the  package  and  the  associated  class  of  mail  used. 


NIMSR  TIME  SEGMENTS 
(Percent  of  Total  Time) 


Source:  OODSSR  Data  Collection 


Figure  1-135 


PICA  completions  are  also  batched  for  the  purpose  of 
sending  a  number  of  replies  under  the  same  cover  letter.  How¬ 
ever,  an  analysis  of  the  individual  transactions  received  during 
the  data  collection  indicates  that  much  larger  batching  occurs  on 
the  SICA  outgoing  request  side  than  occurs  on  the  PICA  outgoing 
advice  side.  The  average  total  time  for  completion  does  seem 
rather  high  considering  that  NIMSRs  are  generally  sent  for  items 
already  stock  numbered  based  upon  the  "First  on  -  First  Manager” 
concept  used  in  the  Lead  ICP  approach  to  managment  of  nonconsum¬ 
able  items.  Under  this  concept  the  first  ICP  bringing  an  item 
into  the  system  is  designated  as  the  manager  of  the  item. 

10.  Summary .  Potential  causes  for  problems  were  mentioned 
and  conclusions  derived  whenever  such  knowledge  was  obtained  as  a 
part  of  the  data  collection,  validation  and  analysis.  However, 
there  are  other  potentially  important  and  even  overriding  reasons 
for  some  of  the  phenomena  observed  from  the  quantitative  analysis 
that  can  be  understood  only  through  a  system  design  analysis  and/ 
or  operational  implementation  review.  Systems  design  analysis 
and  operational  implementation  review  are  described  in  Volume  II. 
Validation  analysis  is  described  in  Chapter  III  of  this  Volume. 

The  results  of  this  Chapter  must  be  considered  in  conjunction 
with  the  systems  design,  implementation  and  validation  analyses 
through  the  comparative  analysis  that  is  presented  in  Chapter  V 
of  Volume  I.  The  observations  and  conclusions  presented  in  this 
Chapter  are  only  preliminary  and  based  upon  the  quantitative  anal¬ 
ysis  prescribed  in  this  Chapter. 
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CHAPTER  II 


AUTODIN/TELEFAX  TEST 


A.  INTRODUCTION 

The  DODSSR  Study  was  assigned  to  review  and  analyze  the 
Supply  Support  Request  (SSR)  processing  and  interrelated  systems 
to  identify  problems  associated  with  the  systems  used  to  generate, 
transmit,  process  and  control  SSRs,  and  to  recommend  improvements 
to  increase  the  effectiveness  and  efficiency  of  these  systems* 

During  numerous  meetings  of  the  Special  Projects  Group  for 
Provisioning  (SPG),  problems  were  Identified  that  relate  to  the 
transmission  and  control  of  SSRs.  The  use  of  AUTODIN  for  SSRs 
was  recommended  as  a  potential  solution  to  problems  associated 
with  the  transmission  of  SSRs  using  the  U.S.  mall.  However, 
there  was  no  universal  agreement  on  the  use  of  AUTODIN  for  this 
purpose.  In  order  to  evaluate  AUTODIN  as  an  alternative,  the 
DODSSR  Study  Group  proposed  to  the  SPG  and  received  approval  from 
the  Office  of  the  Assistant  Secretary  of  Defense  (OASD)  to  con¬ 
duct  an  AUTODIN  test. 

Subsequent  to  the  development  of  the  initial  plans  for  the 
electrical  transmission  of  SSRs  over  AUTODIN,  the  study  team 
developed  and  received  approval  for  a  plan  for  the  electrical 
transmission  of  technical  data  using  telecommunications  facsimile 
(TELEFAX)  equipment.  A  test  plan  containing  test  and  evaluation 
procedures  was  developed  to  monitor  and  coordinate  the  schedul¬ 
ing,  conduct,  control,  and  evaluation  of  the  test.  A  copy  of  the 
detailed  test  plan  is  contained  in  Appendix  I. 

B .  PURPOSE 

The  test  was  conducted  to  determine  the  feasibility  of  trans¬ 
mitting  and  receiving  supply  support  request  management  and  tech¬ 
nical  data  using  electrical  or  electronic  media  in  place  of  the 
current  method  of  mailing  such  data. 

C.  OBJECTIVES 

The  objectives  of  the  test  plan  were  tailored  to  be  compatible 
with  and  accomplish  the  objectives  of  the  Study.  The  specific 
objectives  of  the  test  are  outlined  below. 

1.  Decrease  transmission  times  for  all  types  of  SSR  trans¬ 
actions  being  transmitted  among  SICCs  and  Integrated  Materiel 
Managers  (IMMs).  This  includes  management  and  technical  data 
associated  with  the  following  types  of  transactions. 
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a.  Supply  support  requests  and  changes  to  Initial 
requests  . 

b.  Catalog/technical  data. 

c.  Initial  and  final  advice  on  the  request,  including: 

(1)  Acceptance  of  supply  support  and  NSN  notifica¬ 
tion. 

(2)  Status  advice. 

(3)  Offers  of  alternate  or  substitute  items. 

(4)  Rejects. 

d.  Replies  to  offers. 

e.  Followups  for  advice. 

f.  Responses  to  followups  for  advice. 

2.  Improve  control  and  provide  an  audit  trail  from  the  time 
an  SSR  transaction  has  been  prepared  by  the  submitting  activity 
until  communicated  to  and  received  by  the  receiving  activity  and 
introduced  into  processing. 

3.  Decrease  SSR  loss  rate. 

4.  Improve  processing  efficiency  at  submitter /receiver 
(SICC/IMM)  activities. 

5.  Improve  processing  effectiveness  at  submitter/recei ver 
activities . 

6.  Increase  accuracy  of  submissions. 

D.  SCOPE 


The  test  included  the  transmission  of  all  SICC/CIMM  consum¬ 
able  transactions  transmitted  between  the  participating  activ¬ 
ities  during  the  test  period.  This  included  all  conditions  and 
Document  Identifier  Codes  in  the  SSR  Series,  both  provisioning 
and  nonprovisioning  actions  manually  or  mechanically  generated 
from  any  organizational  element  at  the  participating  activities. 
SICC/VJIMM  transactions  were  excluded  from  the  test. 

1.  Program  Data  Supply  Support  Request  (PDSSR)  Cards,  Docu¬ 
ment  Identifier  Code  CWA. 

2.  Line  Item  Supply  Support  Request  (LISSR)  Cards,  Document 
Identifier  Codes,  CXA,  CXB  and  CXC. 
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3.  Catalog  Cards,  Document  Identifier  Codes  CXF,  CXF,  and  CXK 


4.  Line  Item  Advice  Cards  (LIAC)  (Advice,  Reply,  Followup, 
ResponseT>  CXI ,  CX2 ,  CX3 ,  and  CX4. 

5.  Technical  Data  as  defined  In  MIL-STD-1561 ,  Provisioning 
Procedures,  (Appendix  D,  Reference  23). 

E.  PARTICIPATING  ACTIVITIES 


The  participating  activities  were  selected  based  upon  a  number 
of  considerations.  Geographic  location  was  one  factor.  It  was 
considered  desirable  to  select  activities  located  in  different 
parts  of  the  country  to  test  the  effect  of  distance  on  transmittal 
time.  The  volume  and  type  of  supply  support  request  traffic  among 
submitters  and  receivers  and  the  impact  on  their  operations  during 
the  test  period  was  taken  into  account.  Stage  and  degree  of  im¬ 
plementation  of  automated  procedures  was  another  element.  Poten¬ 
tial  submitter  participants  were  restricted  to  those  visited  by 
the  Study  Team  and  participating  in  the  data  collection  in  order 
to  facilitate  analysis  of  the  test. 


1 .  SICCs  (Submitters) 


Component 


AUTODIN 


Army 

Navy 

Air  Force 


TSARCOM 

SPCC 

SMALC 


2 .  CIMM  (Receiver) 

Component  AUTODIN 

DLA  DGSC 


TELEFAX 


SPCC 

SMALC 


TELEFAX 

DGSC 


F.  SCHEDULE 


The  test  was  conducted  for  a  period  of  four  months.  This  was 
considered  the  minimum  time  required  to  complete  or  close  out  the 
majority  of  transactions.  The  Intent  was  to  permit  experience 
with  all  types  of  transactions  and  it  was  not  expected  that  all 
transactions  initiated  during  the  period  would  be  completed.  The 
test  was  conducted  in  several  parts  and  phases  to  permit  the  eval¬ 
uation  of  a  number  of  alternatives  for  submitting  SSR  transactions 

1.  SSR  Submission.  All  of  the  test  activities  submitted 
their  SSR  request  and  advice  transactions  to  each  other  over 
AUTODIN  during  the  period  1  September  to  31  December  1978. 
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2.  Technical  Data  Submission.  Technical  data  was  submitted 
by  mail  by  TSARCOM  during  th>_  entire  four  months  test  period 
while  sending  their  SSR  cards  over  AUTODIN.  Technical  data  was 
submitted  by  mail  from  1  September  -to  30  September  by  SMALC  and 
SPCC.  During  the  period  from  1  October  to  31  December  1978  SMALC 
and  SPCC  submitted  technical  data  using  a  facsimile  transmission 
system  to  electrically  transmit  technical  data  to  DGSC. 

G.  DESCRIPTION 

1.  Test  Alternatives.  A  number  of  alternatives  were  tested 
either  as  a  direct  part  of  the  AUTODIN/TELEFAX  test  of  different 
systems  and  equipment  for  transmitting  SSR  data  or  indirectly 
through  the  analysis  of  the  current  systems  of  activities  not 
participating  in  the  test,  but  participating  in  the  DODSSR  Study 
field  research  and  data  collection  and  analysis  effort. 

a.  Alternative  1.  Requests  and  technical  data  mailed, 
advice  via  AUTODIN. 

This  alternative  represented  the  system  being  used 
by  the  majority  of  SICCs  and  IMMs  during  the  course  of  the  study. 
The  SSR  Procedures  prescribed  the  use  of  mall  for  requests  and 
permitted  CXI,  CX2 ,  CX3 ,  and  CX4  advice  transactions  to  be  sent 
over  AUTODIN.  AUTODIN  was  used  by  DLA  for  sending  almost  all 
advice  to  SICCs.  Some  package  rejects  were  mailed  by  DLA  and 
exception  advice  was  also  provided  by  mail.  HLA  accounts  for 
over  97Z  of  the  SSR  traffic. 

b.  Alternative  2.  Requests,  technical  data,  and  advice 

mal led . 

This  alternative  was  used  by  some  of  the  Components 
for  WIMM  items  and  by  TARCOM  and  GSA  for  CIMM  items. 

c.  Alternative  3.  All  SSR  transactions  sent  AUTODIN, 
technical  data  mailed. 

During  the  entire  test  period  TSARCOM  used  this 
alternative  for  traffic  with  DGSC.  Test  activities,  SMALC  and 
SPCC,  operated  under  this  alternative  during  September  1978,  for 
their  traific  with  DGSC. 

d.  Alternative  4.  All  SSR  transactions  send  AUTODIN, 
technical  data  by  TELEFAX. 

Traffic  among  SMALC,  SPCC  and  DGSC  during  the  period 
October  to  December  1978  was  transmitted  under  this  alternative. 

A  subset  under  this  alternative  included  the  transmission  of 
technical  data  using  both  analog  and  digital  TELEFAX  systems  by 
SPCC  during  December  1978. 
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a.  AUTODIN .  The  existing  installed  equipment  and  cos* 
munications  networks  at  the  test  activities  were  used  to  transmit 
the  SSR  card  transactions  to  and  from  the  test  activities  during 
the  entire  test  period. 

b.  TELEFAX 

The  DODSSR  Study  Team  surveyed  the  current  state  of 
the  art  that  was  available  to  electrically  transmit  technical 
data  at  the  time  the  test  was  conducted.  The  controlling  factor 
in  the  selection  of  the  mode  and  equipment  for  transmission  was 
the  fact  that  technical  data  consisted  primarily  of  hard  copy 
drawings.  The  activities  involved  in  the  test  all  had  technical 
data  libraries  with  technical  data  on  aperture  cards,  but  the 
availability  of  documentation  at  the  time  of  submission  of  the 
SSR  transaction  cards  was  usually  restricted  to  hard  copy. 


A  second  constraint  was  the  necessity  of  readily 
available  commercial  equipment  during  the  timeframe  available  to 
conduct  the  test.  The  only  commercially  available  equipment  that 
the  Study  Group  research  could  find  that  was  capable  of  scanning 
a  Type  D  drawing  (18"x24")  and  transmitting  it  over  telephone 
lines  was  a  telefacsimile  system  available  under  an  Authorized 
Federal  Supply  Schedule,  GSA  Distribution  Code:  00CC-5802  for 
Fiscal  Year  1978.  This  equipment  scans  a  document,  converts  the 
image  on  the  document  to  a  signal  that  can  be  transmitted  and 
converts  this  signal  back  at  some  distant  point  in  a  recording 
device  that  prints  out  a  facsimile  of  the  original  document.  The 
equipment  can  and  has  been  used  to  transmit  textual,  graphic  and 
pictorial  material  including,  written  text,  weather  maps,  drawings 
and  photographs  over  AUTOVON  or  WATS  lines. 

The  following  types  of  equipment  were  leased  and  in¬ 
stalled  at  the  activities  for  the  periods  of  time  indicated: 

(1)  Analog  Transmit  Terminal.  Two  of  the  analog 
transmit  terminals  were  installed,  one  at  SMALC  and  one  at  SPCC. 
These  terminals  were  in  operation  from  October  through  December 
1978. 

(2)  Digital  Transmit  Terminal.  One  digital  transmit 
terminal  was  installed  at  SPCC  during  December  1978.  The  purpose 
of  Installing  this  terminal  was  to  make  a  comparison  of  copy 
quality  and  transmission  time  with  that  of  the  analog  system. 

(3)  Analog  Receive  Terminal.  This  terminal  was  in¬ 
stalled  and  in  operation  at  DGSC  during  October  through  December 
1978. 


(4)  Digital  Receive  Terminal.  The  digital  terminal 
was  installed  at  DGsti  during  December  T9T8  to  receive  digital 
transmission  from  SPCC  to  compare  with  the  analog  alternative. 

(5)  Communications  Network.  Sending  and  receiving 
equipment  was  coupled  to  existing  AUTOVON  and  WATS  lines.  Sub¬ 
mitting  activities  had  the  option  of  selecting  either  AUTOVON  or 
WATS  lines  at  the  time  of  transmission. 

3.  Test  Procedures 


a.  Submission 


(1)  Participating  activities  submitted  all  SSR  EAM 
card  type  traffic  for  consumable  items  over  AUTODIN  between  Test 
SICC  and  Test  C1MM  activities  only.  An  AUTODIN  content  Indicator 
code  was  assigned  to  identify  this  traffic.  Traffic  included  all 
initial,  change,  resubmission,  advice,  reply,  followup  and  re¬ 
sponse  traffic  for  all  SSR  conditions  using  any  of  the  SSR  docu¬ 
ment  identifier  codes  for  CIMM  items.  The  test  did  not  apply  to 
traffic  flowing  between  test  and  nontest  activities. 


(2)  Submitters  were  encouraged  to  forward  traffic 
to  the  CIMM  immediately  after  generation  and  validation.  The 
same  general  processing  procedures  and  cycles  normally  used  to 
generate  SSRs  for  submission  by  the  conventional  mode  were  used 
for  generation  of  SSRs  for  AUTODIN  submission.  However,  after 
generation  submitters  were  requested  to  use  one  of  the  following 
options . 

(a)  Card  submission  from  ADP/EAM  Keypunch 
Operations  to  AUTODIN  Operations. 


(b)  Tape  submission  from  ADP  Operations  to 
AUTODIN  Operations. 


(c)  Direct  wire  interface  between  ADP  and 
AUTODIN  Operations. 


(3)  Submitters  were  requested  to  establish  controls 
to  ensure  that  SSRs  were  routed  to  AUTODIN  Operations  by  the  most 
expeditious  method  possible  and  that  backup  information  was  re¬ 
tained  in  the  event  of  loss  or  mlsrouting  of  transactions. 


(4)  Copies  of  SSR  transactions  were  sent  to  the 
DODSSR  Study  Group  for  Inclusion  in  the  DODSSR  Data  Base  to  be 
used  to  evaluate  the  test. 


(5)  Submitters  were  also  requested  to  forward  SSRs 
requiring  technical  data  or  supporting  documentation  over  AUTODIN 
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immediately  after  creation  of  the  SSR.  Technical  data  was  sub¬ 
mitted  under  separate  cover  as  expeditiously  as  possible.  Con¬ 
trol  data  was  marked  on  the  face  of  the  technical  documentation 
to  facilitate  matching  up  with  the  SSR  by  the  recipient.  Control 
data  Includes: 

(a)  PCC 

(b)  ISN 

(c)  DOR 

(d)  Activity  Code  (From) 

(6)  Technical  data  for  which  SSRs  were  separately 
forwarded  by  AUTODIN  was  mailed  to  DGSC  during  the  period  1 
September  to  30  September  1978  by  all  test  submitters  and  TSARCOM 
mailed  technical  data  during  the  entire  test.  The  covering  let¬ 
ter  contained  a  reference  to  the  test.  Listings  of  SSRs  generated 
during  the  test  and  forwarded  by  AUTODIN  were  used  to  identify 
and  submit  associated  technical  data. 

(7)  Technical  data  was  forwarded  to  DGSC  via  elec¬ 
trical  facsimile  transmission  during  the  period  1  October  to  30 
December  1978  by  TELEFAX  submitting  activities. 

(a)  Control  data  was  marked  on  the  face  of  the 

technical  data. 

(b)  Technical  data  with  dimensions  of  18"x24" 
or  less  was  electrically  transmitted  and  a  copy  retained  in  the 
PCC  file. 


(c)  Technical  data  on  aperture  cards  was  printed 
and  the  hard  copy  was  used  to  electrically  transmit  the  data  with 
the  hard  copy  maintained  in  the  PCC  file  after  transmission. 

(d)  Oversized  technical  data  (wider  than  18") 
was  electrically  transmitted  using  a  hard  copy  obtained  from  the 
technical  library,  which  was  requested  to  provide  a  minimum  of 
24-hour  turn  around  time  for  aperture  card  print  requests.  If 
the  drawing  was  not  in  the  library,  the  drawing  was  forwarded  in 
18”  wide  segments. 


(e)  Submitting  activities  were  requested  to 
contact  the  receiving  activity  for  guidance  when  technical  data 
could  not  be  forwarded  electrically  due  to  copy  quality,  size, 
multiple  page  commercial  books,  brochures  or  drawings. 
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b .  Receipt,  Control  and  Processing 

(1)  The  CIMM  teat  activity  was  requested  to  establish 
procedures  and  controls  to  ensure  that  the  SSR  transactions  re¬ 
ceived  over  AUTODIN  were  introduced  into  processing  as  expedi¬ 
tiously  and  efficiently  as  possible. 


(a)  SSRs  were  routed  directly  from  AUTODIN 
operations  to  ADP  operations  for  all  transactions. 

(b)  Transactions  for  which  technical  data  was 
not  required  or  could  not  be  provided  were  processed  through  the 
entire  SSR  processing  system.  This  group  of  SSRs  consisted  of: 

_1  Condition  1  SSRs. 

2  Condition  2  SSRs  with  PSCNs. 


3^  SSRs  with  a  Technical  Data  Justification 
Code  (TDJC)  providing  a  reason  why  technical  data  cannot  be 
supplied . 

4^  SSR  accompanied  by  a  CXF  Item  Name  Card. 

_5  A  Condition  3  SSR  that  does  not  require 
technical  data  when  the  manufacturer's  number  in  the  SSR  is  a 
Government  specification  or  standard  including  type  designator 
which  completely  identifies  the  item. 


(c)  Transactions  that  required  the  submittal  of 
technical  data  which  was  not  available  at  the  time  of  submittal 
of  SSRs  but  contained  justification  codes  indicating  the  data 
would  be  provided  in  the  future  were  to  be  processed  and  not  held 
in  abeyance.  The  CIMM  was  requested  to  follow  up  for  technical 
data  in  accordance  with  current  procedures. 


(d)  Transactions  that  required  the  submittal  of 
technical  data  which  was  available  at  the  time  of  submittal  of 
SSRs  were  not  to  be  submitted  with  a  CXF  Item  Name  Card,  date 
technical  data  to  be  supplied,  or  technical  data  justification 
code.  SICCs  were  required  to  forward  technical  data  within  24 
hours  of  AUTODIN  transmission  of  SSRs.  Those  transactions  which 
require  technical  data  but  which  had  not  yet  been  received  by  the 
CIMM  were  processed  through  the  following  actions  pending  the 
receipt  of  technical  data: 


^  Ed  1 1 / Val ldat ion . 

2^  Method  of  Support  (MOS)  Determination/ 
Acquisition  Advice  Code  (AAC)  assignment. 
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Suspense  File 


3^  Recording  of  transactions  in  SSR  Control/ 


4^  DLSC  Screening/Interrogation* 

_5  Rejection  of  invalid  transactions* 

_6  Remaining  actions  were  held  in  abeyance 
pending  receipt  of  the  technical  data.  The  CIMM  was  required  to 
maintain  a  manual  log  to  provide  a  suspense  control  on  all  Part 
Number  Select/NSN  Request  Cards  (DICtYDH)  which  required  match  up 
to  technical  data.  A  Provisioning  Item  History  Envelope  (PIHE) 
was  prepared  as  in  the  nontesting  environment  for  each  Item 
Serial  Number  (ISN).  The  YDH  card  was  placed  in  the  PIHE  until 
technical  data  was  received  or  the  SSR  returned  for  nonsubmittal 
of  technical  data.  In  the  event  technical  data  was  received 
prior  to  the  receipt  of  the  YDH  card,  a  PIHE  was  prepared  and  the 
technical  data  maintained  until  the  YDH  card  was  received.  The 
YDH  cards  requiring  technical  data  were  not  processed  through 
item  entry  control  without  the  technical  data. 

]_  The  CIMM  was  requested  to  review  the 
suspense  control  log  and  notify  the  submitter  seven  days  after 
receipt  of  the  request  over  AUTODIN,  that  if  the  technical  data 
had  not  been  received,  the  request  would  be  rejected  14  days 
after  receipt  of  the  request  if  the  technical  data  still  had  not 
been  received.  A  special  action  taken  code  (ATC  99)  was  estab¬ 
lished  to  provide  this  notification.  If  the  technical  data  was 
not  then  received,  the  request  was  rejected  using  ATC  44  because 
of  lack  of  technical  data. 


8^  Technical  data  provided  by  a  submitter 
for  an  SSR  which  was  rejected  was  held  by  the  CIMM  for  resubmit- 
tal  of  the  SSR.  The  SSR  being  resubmitted  was  required  to  con¬ 
tain  the  same  provisioning  control  data  (PCC / ISN/ Submit t ing 
Activity  Code)  as  the  original  (rejected)  SSR  with  the  exception 
of  the  date  of  request  (DOR). 


established 
by  the  SICC 
was  matched 


(2)  Procedures  and  controls  were  required  to  be 
to  ensure  that  supporting  technical  data  was  provided 
and  received  by  the  CIMM  and  that  the  technical  data 
with  the  appropriate  SSR  transactions  for: 


(a)  Initial  and  revised  SSRs. 


(b)  Offers  of  alternate  and  substitute  items. 


H.  EVALUATION 

1.  Plan.  Evaluation  of  the  effectiveness  and  efficiency  of 
the  Test  was  a  joint  effort  among  the  Test  Participating  Activ¬ 
ities  (SICCs/CIMM)  and  the  DODSSR  Study  Team.  Three  types  of 
evaluation  were  performed. 


a.  Participating  activities  provided  an  evaluation  of 
the  effects  of  the  test  on  their  operation  in  terms  of  the  test 
objectives  in  accordance  with  evalution  guidelines  provided  by 
the  Test  Plan. 

b.  The  DODDSR  Study  Team  evaluated  the  accomplishment  of 
the  objectives  through  analyses  performed  on  transactions  sub¬ 
mitted  in  the  data  collection. 

c.  The  DODSSR  Study  Team  reviewed  and  compared  the  re¬ 
sults  of  the  test  based  upon  an  analysis  and  comparison  of  par¬ 
ticipating  activity  evaluation  reports,  the  data  collection/ 
analysis  and  operational  review  of  the  SSR  processes  at  the  par¬ 
ticipating  activities. 

2.  Analyst s .  The  purpose  of  the  test  was  to  determine  the 
feasibility  of  electrically  transmitting  SSR  transactions  and 
associated  technical  data.  Test  objectives  were  established  and 
criteria  developed  to  measure  the  accomplishment  of  the  objec¬ 
tives  in  order  to  determine  the  feasibility  and  relative  effec¬ 
tiveness  of  each  of  the  test  alternatives.  The  evaluations  exam¬ 
ine  the  measurements  in  accordance  with  the  test  criteria  for 
each  of  the  alternatives  and  display  the  results  for  each  of  the 
test  objectives.  Determination  of  feasibility  of  test  alter¬ 
natives  was  then  made  by  comparing  the  relative  accomplishment  of 
the  test  objectives  for  each  alternative  and  ranking  the  alter¬ 
native  in  order  of  preference  for  the  test  objectives  individ¬ 
ually  and  in  combination  with  each  other. 

a .  Transmission  Times 

( 1 )  SSR  Transactions 

The  submission/transmission  time  reports  that 
were  produced  to  generate  the  statistics  shown  in  Volume  III  for 
the  Steady  State  Population  were  also  produced  for  the  AUTODIN 
Test  and  Non-AUTODIN  Test  population.  These  populations  were 
then  compared  to  determine  the  effect  of  the  AUTODIN  Test  on 
submis s ion / t ransm is s ion  time  for  supply  support  request  transac¬ 
tion  cards.  The  table  in  Figure  II-l  summarizes  the  results  of 
this  analysis  . 

The  table  shows  the  net  transfer  times  for  each 
of  the  major  transaction  categories.  The  AUTODIN  Test  population 
includes  only  those  activities  that  participated  in  the  test  and 
only  for  transactions  that  occurred  during  the  test  period  and 
were  submitted  by  AUTODIN.  The  Non-AUTODIN  Test  population  in¬ 
cludes  requests  that  were  mailed  during  the  test  period  by  activ¬ 
ities  not  participating  in  the  test  and  requests  that  were  mailed 
by  test  activities  during  the  nontest  period.  During  the  nontest 
period  it  was  optional  as  to  whether  an  activity  mailed  or  sub¬ 
mitted  CXI,  2,  3,  and  4  advice  transactions  by  mall  or  AUTODIN. 
The  SSR  Procedures  prescribe  the  mandatory  use  of  mail  for 
requests  and  the  optional  use  of  AUTODIN  for  advice  transactions. 


AUTODIN  TEST  NET  SUBMISSION/TRANSMISSION  TIMES 
(Number  of  Days  by  Transaction  Type) 


Transaction 

Popula  t ion 

Mean 

50%-ILE 

90%-ILE 

Requests 

AUTODIN  Test 

— 

1 

26 

Non-AUTODIN  Test 

15 

31 

Advice 

AUTODIN  Test 

1.9 

1 

4 

Non-AUTODIN  Test 

4.0 

1 

6 

Reply 

AUTODIN  Test 

1.8 

2 

3 

Non-AUTODIN  Test 

1.0 

i 

3 

Followup 

AUTODIN  Test 

mm 

i 

3 

Non-AUTODIN  Test 

i 

2 

Response 

AUTODIN  Test 

2.0 

i 

5 

Non-AUTODIN  Test 

2.5 

2 

4 

Source:  DODSSR  Data  Collection 


Figure  II-l 

The  statistics  in  Figure  II-l  indicate  that  there 
clearly  is  an  advantage  in  savings  of  transmission  time  for  re¬ 
quests.  The  table  shows  an  average  savings  of  one  week  and  a  two 
weeks  saving  50%  of  the  time.  However,  these  statistics  represent 
a  mix  of  data  processing  and  batching  techniques  used  to  transfer 
the  requests  from  computer  operations  to  AUTODIN  operations  for 
actual  transmission  of  the  transactions. 


The  Air  Force  created  a  magnetic  tape  of  the 
requests  which  were  submitted  over  AUTODIN  on  a  daily  basis.  The 
Air  Force  net  transfer  time  using  this  procedure  was  from  one  to 
three  days,  which  approaches  the  pure  AUTODIN  transmit  time  of 
one  to  three  days  reported  in  Chapter  I.  The  Army  and  Navy  used 
a  combination  of  data  processing,  functional  processing,  schedul¬ 
ing  and  batching  techniques  that  introduced  up  to  two  to  three 
weeks  extra  internal  processing  time  into  their  net  submission 
time.  The  extra  internal  processing  time  is  confirmed  by  their 
AUTODIN  transmit  times  which  range  from  one  to  three  days  and  the 
procedures  outlined  in  their  evaluation  reports.  If  the  Air  Force 
technique  is  used  an  average  savings  of  two  to  three  weeks  can  be 
obtained  by  using  AUTODIN  in  place  of  mail.  However,  if  the 
requests  are  not  routed  directly  to  AUTODIN  operations  for  trans¬ 
mission  immediately  after  creation,  there  may  be  little  or  no 
savings  in  time  realized. 


The  CXI  advice  transmission  times  are  dominated 
by  OLA  due  to  the  volume  of  DLA  business.  The  net  processing 
times  for  advice  approach  the  AUTODIN  transmit  time  particularly 
during  the  AUTODIN  Test  period.  The  slightly  higher  figures  for 
the  Non-AUTODIN  Test  period  are  due  to  the  use  of  manual  and  mail 
procedures  for  WIMM  advice  transactions.  If  the  advice  is  gener¬ 
ated  on  a  daily  basis  and  immediately  transferred  from  data  pro¬ 
cessing  operations  to  AUTODIN  operations  it  should  take  an  average 
of  one  day  during  the  week  and  three  days  if  a  weekend  is  involved. 

Reply  times  approach  the  one  to  three  day  AUTODIN 
transmit  times  for  both  test  periods.  The  offer/reply  sample  size 
for  the  AUTODIN  Test  population  represented  only  71  Air  Force 
transactions.  The  Air  Force  volumes  dominated  the  Non-AUTODIN 
Test  statistics  and  kept  the  times  low.  The  Navy  averaged  about 
two  weeks  submission  time  for  replies. 

Followups  are  also  generally  sent  out  over 
AUTODIN,  by  most  SICCs,  so  they  are  representative  of  AUTODIN 
transmit  time.  To  the  extent  that  they  are  created,  followups 
are  usually  computer  generated,  so  there  is  less  manual  pro¬ 
cessing  and  batching  involved. 

Responses  are  predominantly  sent  out  by  AUTODIN 
and  are  dominated  by  DLA  volumes. 

The  evaluation  reports  by  the  activities  partic¬ 
ipating  in  the  AUTODIN  Tests  confirmed  that  the  use  of  AUTODIN 
resulted  in  a  net  decrease  in  transmission  time.  Both  submitters 
and  the  receiver  reported  that  they  had  experienced  an  improve¬ 
ment  in  transmission  time  for  SSR  transactions  during  the  AUTODIN 
Test . 

( 2 )  Technical  Data 

Technical  data  when  mailed  will  experience  the 
transmission  time  reported  in  Figure  II-l  for  the  Non-AUTODIN 
Test.  The  requirement  to  submit  technical  data  for  new  items  is 
the  principal  factor  requiring  the  use  of  mail  for  SSR  transac¬ 
tions.  The  AUTODIN/TELEFAX  Test  included  two  alternatives  for 
transmission  of  technical  data.  The  transmission  of  SSRs  by 
AUTODIN  and  mailing  of  technical  data  was  performed  to  determine 
if  the  transmission  of  SSR  transactions  and  technical  data  could 
be  separated  and  if  it  would  result  in  Improvements  in  the  trans¬ 
mission,  processing  and  control  of  SSRs.  Although  the  transmis¬ 
sion  time  for  the  SSR  transactions  sent  by  AUTODIN  is  reduced, 
the  mailing  of  technical  data  separately  from  the  SSR  transac¬ 
tions  after  creation  of  the  SSR  transaction  does  not  decrease  the 
transmission  time  for  technical  data.  The  advantage  of  sepa¬ 
rately  mailing  the  technical  data,  if  any,  must  be  attributed  to 
a  reduction  in  net  processing  time,  improvement  in  processing 
efficiency  or  effectiveness,  or  an  improvement  in  control. 
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The  TELEFAX  Test  was  performed  to  determine  if 
the  transmission  time  for  technical  data  could  be  reduced  through 
electronic/electrical  transmission.  Two  Analog  Transmit  Terminals, 
one  Digital  Transmit  Terminal,  one  Analog  Receive  Terminal  and 
one  Digital  Receive  Terminal  were  installed  at  participating 
activities  to  transmit  technical  data  from  the  Test  SICCs  to  the 
Test  CIMM.  The  equipment  was  coupled  to  standard  AUTOVON  and 
WATS  voice  grade  lines.  The  sender  had  the  option  of  selecting 
either  of  the  two  lines  at  the  time  of  transmission.  Generally, 
AUTOVON  was  used  unless  it  was  busy  or  interruptions  were  being 
experienced. 

The  transmission  system  consisted  of  the  input 
source  document,  the  operator  of  the  sending  unit,  the  communica¬ 
tions  networks,  the  receiving  unit,  the  operator  of  the  receiving 
unit  and  the  output  facsimile  document.  The  source  documents 
were  hard  copy  technical  data  consisting  of  standard  drawings 
types  A  to  F,  catalog  pages,  technical  data  sheets,  and  other 
types  of  technical  data.  The  technical  data  is  used  by  the  IMM 
to  perform  item  entry  control  and  stock  numbering  actions.  After 
completion  of  technical  actions,  some  of  the  technical  data 
(usually  drawings)  are  converted  to  aperture  cards  for  entry  into 
the  IMMs  technical  data  library. 

Figure  II-2  provides  an  estimate  of  the  time  to 
transmit  drawings  by  type  and  size  using  analog  equipment.  The 
times  shown  are  the  approximate  times  using  voice  grade  lines 
without  interruptions.  The  time  to  transmit  a  document,  assuming 
no  interruptions,  is  a  function  of  the  size  of  the  document,  the 
density  of  the  printed  or  graphic  material  on  the  document,  and 
the  scan  and  transmit  speed  selected.  The  data  shown  in  the 
table  provides  approximations  assuming  a  scanning  rate  of  120 
revolutions  per  minute  (RPM).  Reading  from  left  to  right,  as  the 
size  of  the  document  increases,  the  transmit  time  Increases. 

Reading  from  top  to  bottom,  as  the  density  (Lines  per  Inch)  of 
the  document  increases,  the  transmit  time  is  also  increased. 

The  evaluation  reports  submitted  by  the  test 
activities  tend  to  support  the  estimated  transmission  times  for 
the  analog  and  digital  systems.  Average  times  of  6.85  minutes 
were  reported  for  the  analog  system  and  1.9  minutes  for  the  digi¬ 
tal  system  when  there  were  no  interruptions  of  equipment  down¬ 
time.  The  digital  system  can  transmit  at  a  much  faster  rate  than 
the  analog  system.  Digital  equipment  is  estimated  to  be  about 
four  times  faster  than  analog  equipment. 
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ANALOG  TELEFAX  TRANSMISSION  TIME 


(Approximate  Time 

in  Minutes  to  Transmit 
TYPE  DRAWINGS 

Over  3  KHZ 

Voice  Line) 

RPM 

LPI 

A 

B 

C 

D  E 

F 

120 

96 

6.8 

8.8 

17.6 

17.6  35.2 

32.0 

120 

120 

8.5 

11.0 

22.0 

22.0  44.0 

40.0 

120 

166 

11.8 

15.3 

30.6 

30.6  61.2 

56.0 

RPM  - 

Revolutions 

per  Minute 

LPI  *  Lines  per  Inch 

Source:  Adapted  from  "The  Facsimile  Series,”  reprinted  from 

Communications  Journal* 


Figure  II-2 

The  activity  evaluation  reports  and  logs  indi¬ 
cate  that  the  normal  transmit  times  for  the  TELEFAX  equipment 
were  sometimes  extended  due  to  the  inability  to  obtain  an  AUTOVON 
or  WATS  line  because  they  were  busy.  Sometimes  there  were  inter¬ 
ruptions  on  AUTODIN  lines  that  necessitated  a  retransmission  of  a 
document  that  had  been  partially  transmitted.  Extremely  long 
drawings  that  exceeded  the  18”  width  limitation  had  to  be  reduced 
or  sent  in  pieces,  thus  incurring  additional  time. 

The  evaluation  reports  and  logs  did  show  that 
when  the  TELEFAX  sys.tems  were  operating  the  technical  data  was 
transmitted  and  received  prior  to  the  generation  of  the  part 
number  select  list  used  to  perform  item  entry  control  and  stock 
number  request  actions.  If  there  was  a  backlog  of  technical  data 
to  send  or  there  were  interruptions,  busy  signals  or  equipment 
downtime,  the  drawings  sometimes  were  received  after  the  part 
number  select  listing  was  generated.  When  TELEFAX  drawings  were 
received  they  generally  were  received  prior  to  the  part  number 
select  listing  or  within  a  few  days  after.  Rejects  for  lack  of 
technical  data  were  generally  sent  because  the  technical  data  was 
not  received  at  all  as  opposed  to  being  received  late.  Some  ATC 
44  rejects  (indicating  no  technical  data)  were  sent  when  tech¬ 
nical  data  was  actually  received,  but  was  inadequate  for  minimum 
reference  type  cataloging  identification.  An  ATC  YS  should  have 
been  sent  when  technical  data  was  received  but  was  inadequate. 


Drawings  were  mailed  by  TSARCOM  during  the 
AUTODIN  Test.  Drawings  were  also  mailed  by  SMALC  and  SPCC  when 
there  was  a  backlog  of  drawings  to  transmit  due  to  the  amount  of 
data  to  sent  or  due  to  TELEFAX  system  problems.  Sometimes 
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drawings  that  were  mailed  were  still  received  prior  to  or  shortly 
after  the  SSR  transaction  had  been  received,  validated  and  pro¬ 
visioning  screening  performed  with  DLSC. 

The  time  to  transfer  a  drawing  by  mail  is  a  func¬ 
tion  of  the  time  to  select  and  match  a  drawing  to  an  SSR,  time  to 
package  the  drawing  for  mailing,  mail  time,  the  time  to  receive, 
unpack,  sort  and  establish  a  PCC  file  for  the  drawings.  The 
drawing  must  then  be  matched  again  with  the  SSR  by  the  receiver 
of  the  SSR  after  the  SSR  has  been  input  for  computer  processing 
to  validate  the  transaction,  perform  DLSC  screening  and  to 
generate  a  part  number  select  list  for  part  numbers  that  could 
not  be  matched  to  an  NSN. 

(3)  Summary .  In  terms  of  transmission  time,  the 
analysis  of  evaluation  reports  and  logs  indicates  that  the  alter¬ 
native  of  transmitting  SSRs  and  technical  data  electrically  is 
feasible.  However,  the  TELEFAX  systems  tested  take  too  long  to 
transmit  large,  high  density  pieces  of  technical  data  predicated 
upon  the  volume  of  technical  data  to  be  transmitted.  Conceptually 
an  SSR  transaction  and  technical  data  can  be  electrically  trans¬ 
mitted  separately,  received  and  matched  together  with  a  net 
savings  in  transmission  time  over  mailing  the  SSR  and  the  tech¬ 
nical  data  or  over  forwarding  the  SSR  over  AUTODIN  and  mailing 
the  technical  data.  If  the  technical  data  is  mailed  before  the 
SSR  is  generated  and  sent  over  AUTODIN,  it  is  still  possible  to 
realize  a  net  savings  in  transmission  time  over  mailing  the  SSR 
and  the  technical  data  together. 

b.  Control 


Control  of  a  system  involves  the  ability  to  accurately 
generate,  submit  input  transactions  and  to  process  the  input  trans 
actions  in  a  timely  manner  in  order  to  produce  a  desired  output. 
The  system  should  be  capable  of  precluding  the  loss  of  transac¬ 
tions  from  the  system  and  provide  an  audit  trail  to  record,  track 
and  control  all  events  that  take  place  during  the  life  cycle  of  a 
chain  of  related  transactions. 

A  transaction  can  be  lost  to  the  system  if  it  is  sub¬ 
mitted  and  not  received  or  if  it  is  submitted  and  not  recorded  in 
the  system.  A  transaction  can  also  be  temporarily  lost  to  the 
system  if  it  takes  too  long  in  transit  from  one  system  to  another 
or  if  related  transactions  cross  each  others  paths  in  the  com¬ 
munications  network.  To  the  extent  that  the  status  of  transac¬ 
tions  are  not  recorded  in  the  system,  the  files  of  the  system 
reflect  a  certain  degree  of  inaccuracy. 

An  example  of  temporarily  or  permanently  lost  trans¬ 
actions  was  previously  described  in  the  case  of  advice,  follow¬ 
ups  and  responses.  If  a  request  transaction  is  delayed  in  transit 


207 


or  not  yet  recorded  in  a  suspense  file  and  an  advice  is  delayed 
in  process  or  in  transit,  this  can  result  in  a  followup  being 
sent  out  to  determine  the  status  of  a  request.  If  the  initial 
transaction  has  not  been  recorded  in  the  file  it  will  appear  to 
be  lost  and  a  No  Record  advice  will  be  provided  indicating  that 
the  request  is  not  in  the  system.  If  the  request  is  subsequently 
received  and/or  recorded  in  the  suspense  file,  the  No  Record  reply 
may  cause  a  duplicate  transaction  to  be  submitted,  with  advice  on 
the  initial  transaction  being  received  by  the  submitter  after  the 
resubmlsslon  has  taken  place.  The  above  actions  represent  a  lack 
of  control  in  the  system  in  terms  of  accuracy  of  files,  loss  or 
temporary  loss  of  records  and  an  inadequate  audit  trail.  A 
number  of  reports  were  generated  to  determine  if  the  electrical 
transmission  of  management  and  technical  data  could  improve  the 
control  of  the  SSR  System.  An  analysis  of  these  reports  is  pre¬ 
sented  below. 

( 1 )  Followups/ Responses 

An  analysis  of  followups  and  responses  was  made 
for  the  AUTODIN  and  Non-AUTODIN  Test  period.  This  analysis  indi¬ 
cated  that  there  was  an  85%  reduction  in  the  number  of  followups 
in  relation  to  the  number  of  requests  for  the  principal  submitter 
of  followups  during  the  AUTODIN  Test.  The  receiving  activity 
experienced  an  overall  reduction  of  70%  in  the  followups  during 
the  corresponding  test  period  for  all  activities  participating  ip 
the  test.  A  review  of  the  response  to  the  followups  indicated 
that  the  rate  of  No  Record  responses  dropped  by  68%  during  the 
AUTODIN  Test  period. 

These  statistics  reflect  an  increase  in  control 
over  the  status  of  SSR  transactions.  This  was  caused  because 
requests  were  being  recorded  in  the  suspense  files  of  the  IMM  at 
an  earlier  point  in  relation  to  the  date  of  request  than  during 
the  Non-AUTODIN  Test  period.  The  decrease  in  the  transmission 
time  for  the  request  coupled  with  a  more  direct  transfer  from 
AUTODIN  to  computer  operations  in  place  of  the  transfer  from  mail 
to  the  functional  component  to  computer  operations  placed  the 
request  transaction  in  the  suspense  file  prior  to  the  receipt  of 
the  followup.  In  addition,  since  the  request  was  received 
earlier,  some  of  them  were  completed  and  advice  had  already  been 
transmitted  and  received,  thus  precluding  the  necessity  for  a 
follow  up.  When  a  No  Record  advice  is  received,  some  SICCs  pre¬ 
pare  and  resubmit  a  duplicate  SSR.  The  reduction  in  the  No 
Record  responses  reduced  the  resubmissions  by  a  corresponding 
amount  thus  increasing  the  accuracy  of  the  system. 

(2)  Offers/ Re  plies.  During  the  Non-AUTODIN  Test 
period,  5.7%  of  SMALC's  rejects  were  attributed  to  ATC  08  support 
rejects  because  the  reply  to  the  offer  had  not  been  received  in 
time.  During  the  AUTODIN  Test  period  the  ATC  08  reject  rate 


declined  99%.  However,  during  the  Non-AUTODIN  Test  period  SPCC 
experienced  a  0.6%  ATC  08  reject  rate  which  increased  to  2.1% 
during  the  AUTODIN  Test.  This  is  attributed  to  the  batching/ 
scheduling  technique  used  by  SPCC  to  transmit  over  AUTODIN  while 
the  Air  Force  transmitted  their  transactions  on  a  daily  basis. 
Although  AUTODIN  can  decrease  submission/transmission  time,  net 
savings  will  not  be  realized  unless  the  AUTODIN  system  is  used  in 
conjunction  with  an  appropriate  batching/scheduling  system  by  the 
data  processing  and/or  functional  operational  elements. 


(3)  Summary .  Both  the  quantitative  analysis  and 
evaluation  reports  of  the  test  SICCs  and  IMM  support  the  conclu¬ 
sion  that  the  use  of  AUTODIN  for  SSR  transactions  tends  to  im¬ 
prove  control  of  the  SSR  process.  The  test  SICCs  felt  that  there 
was  an  improvement  in  the  control  of  technical  data  as  well.  The 
test  IMM  felt  that  there  was  less  control  over  the  submission, 
receipt  and  processing  of  technical  data.  The  log  maintained  by 
the  test  IMM  seemed  to  indicate  that  there  was  probably  a  better 
audit  trail  of  both  the  submission  and  receipt  of  technical  data 
and  therefore  there  was  more  control  in  that  respect.  The  ques¬ 
tion  of  the  amount  of  technical  data  received  will  be  discussed 
under  processing  effectiveness  b<*low.  The  audit  trail  associated 
with  technical  data  under  the  TELEFAX  Test  was  probably  a  function 
of  the  conduct  of  the  test  itself.  The  electrical  transmission 
system  tested  does  not  in,  and  of  itself,  lend  itself  to  the  crea¬ 
tion  and  maintenance  of  an  automated  suspense  and  control  system 
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the  AUTODIN/TELEFAX  Test  and  to  determine  if  the  test  resulted  in 
net  improvement  in  performance. 


(1)  Frequency  Distribution.  The  distribution  and 
frequency  of  transactions  were  analyzed  for  the  AUTODIN,  Non- 
AUTODIN,  TELEFAX,  and  Non-TELEFAX  Test  populations.  Generally 
the  frequency  of  occurrence  of  single  open  request  transactions 
was  less  in  all  the  AUTODIN  Test  populations  than  during  the  Non- 
AUTODIN  Test  population.  There  were  13.3%  more  request  transac¬ 
tions  without  any  kind  of  an  accept,  reject  or  offer  advice  than 
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in  the  AUTODIN  Test  populations.  This  indicates  that  more  advice 
was  received  during  the  AUTODIN  Test  periods  and  was  received 
sooner,  thus  the  system  was  more  effective  and  efficient  in  terms 
of  this  measurement  during  the  AUTODIN  Test.  No  determination 
could  be  made  as  to  the  relative  effectiveness/efficiency  of  the 
TELEFAX  versus  the  Non-TELEFAX  periods  because  the  percentage  of 
transactions  with  advice  not  received  was  closer  together  for  the 
two  populations.  In  addition,  because  of  the  backlogs,  system 
interruptions  and  conditions  experienced  during  the  TELEFAX 
period,  some  of  the  technical  data  was  mailed  in  place  of  being 
transmitted  via  TELEFAX  during  the  test.  The  DODSSR  Data  Base 
could  not  be  used  to  isolate  on  a  transaction  basis,  which  SSR 
transactions  forwarded  by  AUTODIN  had  their  associated  technical 
data  forwarded  by  TELEFAX  or  by  mail. 

(2)  Completion  of  Individual  Transaction  Events. 

The  use  of  an  electrical  or  electronic  system  for  transmitting  a 
document  whether  it  is  an  SSR  transaction  or  a  drawing  can  not 
directly  decrease  the  time  to  accomplish  a  particular  processing 
activity.  However,  the  transmission  system  indirectly  can  in¬ 
fluence  the  completion  time  for  an  event  by  decreasing  the  time 

to  transfer  a  document  from  one  processing  activity  to  another  by 

reducing  pure  transmit  time,  facilitating  direct  routing  from  one 
automated  processing  routine  to  another,  eliminating  wait  time 
and  eliminating  the  need  for  certain  manual  processing  actions. 
Timing  of  activities  and  events  can  be  controlled  or  coordinated 
to  permit  the  accomplishment  on  one  or  more  actions  on  SSR  trans¬ 
actions  while  other  actions  such  as  item  entry  control  awaiting 

other  material  such  as  technical  data  may  be  able  to  be  commenced 
earlier  in  time  because  previously  required  tasks  such  as  valida¬ 
tion  and  provisioning  screening  actions  had  been  performed  earlier 
on  SSR  transactions. 

(a)  Requests .  It  takes  from  two  weeks  to  one 
month  or  more  to  send  requests  using  mall  counting  internal  pro¬ 
cessing  time  at  the  sender  and  receiver  and  the  actual  mail  time. 
The  AUTODIN  time  is  from  one  to  three  days.  Using  AUTODIN  a 
savings  of  15  to  30  days  can  be  realized. 

(b)  Accept  Advice.  Accept  advice  on  stock  num¬ 
bered  items  and  initial  accept  on  part  numbered  items  can  be 
reduced  by  approximately  two  to  three  weeks  if  AUTODIN  is  used 
for  submission  of  the  request,  provisioning  screening  and  return 
of  the  advice  to  the  requestor. 

(c)  Reject  Advice.  Validation  rejects  can  be 
received  much  faster  if  the  request  and  the  advice  are  trans¬ 
mitted  over  AUTODIN.  Savings  are  realized  principally  in  the 
internal  processing  times  at  the  SICC  and  IMM  plus  the  transmis¬ 
sion  time.  If  AUTODIN  were  used  both  ways  a  validation  reject 
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could  be  received  within  a  week's  timeframe  as  opposed  to  the 
three  to  four  weeks  timeframe  if  the  request  and  advice  were  sent 
by  mail*  Rejects  as  a  result  of  DLSC  screening  would  take  about 
a  week  longer*  Part  number  rejects  would  take  longer,  contingent 
upon  the  type  of  reject,  but  the  minimum  savings  to  be  realized 
should  be  the  net  transfer  time  by  mall  minus  the  net  transfer 
time  by  AUTODIN. 


(d)  Offer/Reply  *  Offer/reply  Involves  a  minimum 
of  three  transactions;  a  request,  an  offer  and  a  reply.  Savings 
attributable  to  AUTODIN  would  be  the  additive  of  the  difference 
between  the  net  mail  and  AUTODIN  transfer  times.  Reject  of  sup¬ 
port  (withdrawal  of  an  offer)  would  be  reduced  by  the  elimination 
of  most  of  the  ATC  08  rejects  due  to  the  use  of  AUTODIN. 

(e)  Followup/ Response.  The  total  cycle  for  a 
followup  and  a  response  can  be  reduced  to  two  to  three  days  if  a 
weekend  is  not  involved  and  from  four  to  seven  days  if  a  weekend 
is  involved.  This  assumes  the  automated  generation  of  the  re¬ 
sponse  by  the  sender,  the  automated  generation  of  the  response 
by  the  receiver  of  the  followup  and  the  use  of  AUTODIN  by  both 
the  sender  and  receiver  of  the  followup. 

(3)  Completion  of  Transaction  Chain  Events.  Differ¬ 
ences  in  the  processing  times  for  transaction  chain  patterns  using 
mall  versus  AUTODIN  are  a  function  of  the  number  of  transactions 
in  the  chain  under  each  of  the  alternatives  and  the  transfer 
times  for  each  of  the  transactions  in  the  chain.  The  frequency 
distribution  for  AUTODIN  versus  Non-AUTODIN  Test  populations 
showed  that  the  number  of  transactions  per  chain  were  reduced 
significantly  using  AUTODIN.  This  was  due  chiefly  to  the  elimina¬ 
tion  of  single  followups,  multiple  followups,  support  rejects, 
and  resubmission  of  requests  on  a  No  Record  advice  condition. 

Since  the  total  chain  time  is  derived  by  summing  the  individual 
submission  and  processing  times  for  each  of  the  transaction  types 
in  the  chain,  total  chain  time  was  reduced  because  the  chains 
were  shorter  and  thus  contained  fewer  submission  and  processing 
times  to  add  up.  In  addition  AUTODIN  Test  population  times  for 
chains  identical  to  Non-AUTODIN  Test  populations  will  take  less 
time  corresponding  to  the  sum  of  the  differences  of  the  net  trans¬ 
fer  times  for  AUTODIN  and  Non-AUTODIN  for  all  the  transactions  in 
the  chain. 

(4)  Completion  of  Processing  Events.  The  principal 
activities  Involved  in  the  life  cycle  of  the  supply  support 
request  system  involve  wait,  transmit  and  processing  activities. 
Any  improvement  in  the  system  must  be  realized  through  the  elimi¬ 
nation,  reduction  or  modification  of  these  activities.  Each  of 
the  activities  in  the  SSR  process  that  can  be  affected  either 
directly  or  indirectly  by  the  electrical  transmission  of  SSR 
transactions  and  technical  data  is  discussed  below  in  terms  of 
their  normal  order  of  occurrence  on  a  time  sequential  basis. 


(a )  SICC  SSR  Generation  and  Submission  Processing 


The  SICC  processing,  for  the  purpose  of  this 
analysis,  commences  with  the  generation  of  the  request.  After 
the  request  is  generated,  the  SSRs  in  card  or  listing  form  are 
sent  to  the  functional  area  for  matching  with  technical  data  and 
packaging  for  mailing.  After  being  packaged,  the  SSRs  and  tech¬ 
nical  data  are  forwarded  through  the  Internal  mail  system  and  the 
U.S.  mail  to  the  IMM.  The  principal  times  involved  are  the  times 
to  transfer  the  SSR  transactions  to  the  functional  area,  the  wait 
times  in  the  functional  area,  the  time  to  match  drawings  with  SSRs, 
the  time  to  package  the  SSR  transactions  and  technical  data,  the 
wait  times  at  the  internal  mail  facilities  and  the  actual  time  to 
transmit  by  mail.  This  takes  from  two  to  four  weeks  and  more  for 
requests  with  an  NSN,  PSCN  or  part  number. 

Other  than  the  requirement  for  sending 
technical  data  with  SSR  transactions  and  the  custom  of  processing 
SSRs  in  packages,  there  is  no  reason  why  all  SSR  transactions 
need  be  constrained  by  the  time  and  procedures  used  for  those  SSRs 
requiring  technical  data.  If  SSRs  not  requiring  technical  data, 
were  sent  by  AUTODIN  as  opposed  to  mail,  a  savings  of.  one  to  two 
weeks  can  be  realized  in  the  internal  processing  and  wait  times 
associated  with  the  manual  activities  currently  performed  in  sub¬ 
mitting  supply  support  requests  by  mail. 

SSR  transactions  not  requiring  technical 
data  include  SSRs  with  NSNs,  PSCNs  and  those  part  numbered  SSR 
items  containing  a  date  technical  data  is  to  be  supplied  or  a 
technical  data  justification  code  indicating  that  technical  data 
i 8  not  available  and  will  not  be  supplied.  About  40%  of  the  SSRs 
with  part  numbers  are  not  provided  with  technical  data  under  the 
current  system.  About  52%  of  the  requests  are  for  NSN  items,  48% 
for  part  numbered  items  and  less  than  1%  for  PSCNs.  This  means 
that  over  70%  of  all  the  requests  that  are  sent  do  not  contain 
technical  data  but  are  constrained  by  the  submission  method  of 
the  30%  that  do.  Clearly,  those  SSRs  that  do  not  require  tech¬ 
nical  data  could  be  split  out  from  those  that  do  and  be  sent  by 
AUTODIN.  The  question  remains  as  whether  there  is  any  benefit  to 
be  gained  from  also  sending  the  part  number  SSRs  by  AUTODIN  and 
separately  sending  the  technical  data  by  another  electrical  mode 
or  by  mail. 


The  advantage  of  sending  the  part  number 
SSRs  by  AUTODIN  separately  from  the  technical  data  lies  in  the 
potential  for  savings  in  internal  processing  time  at  the  SICC  and 
IMM  and  in  the  transmission  time  if  the  technical  data  can  be 
sent  electrically,  or  if  the  technical  data  can  be  mailed  prior 
to  the  submission  of  the  SSR.  If  the  control  data  can  be  anno¬ 
tated  on  the  technical  data  prior*  to  the  generation  of  the  SSR, 
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it  can  be  forwarded  separately  by  mall  prior  to  the  generation  of 
the  SSR  transaction  with  an  estimated  savings  of  one  to  two  weeks 
in  net  transfer  time  attributable  to  the  savings  in  internal  pro¬ 
cessing  time  at  the  SICC. 

(b)  Transml s s ion .  The  transmission  time  is  a 
function  of  the  media  and  mode  of  transmission.  If  AUTODIN  is 
used  for  SSR  transactions  a  savings  of  two  to  three  weeks  trans¬ 
mission  time  can  be  realized  as  shown  by  the  AUTOTIN  Test  activ¬ 
ities.  If  the  drawing  is  sent  electrically,  the  time  will  ap¬ 
proach  the  transmit  time  for  electrical  transmission  of  SSR  cards 
over  AUTODIN.  The  TELEFAX  Test  indicates  that  it  is  possible  to 
significantly  Improve  the  transmit  times  for  technical  data.  How¬ 
ever,  submitters  and  receivers  of  the  technical  data  using  the 
TELEFAX  system  experienced  some  difficulties  with  that  system. 
Since  these  difficulties  are  more  associated  with  processing  they 
will  be  discussed  under  IMM  processing  below.  The  actual  trans¬ 
mission  time  for  hard  copy  drawings  will  probably  not  be  reduced 
by  mailing  separately  from  the  SSR  transactions  alone.  However, 
there  is  a  potential  for  direct  savings  in  mail  time  if  aperture 
cards  were  mailed  using  higher  class  mail  due  to  the  smaller  bulk 
and  easier  handling  of  the  aperture  cards  over  hard  copy  drawings. 
Otherwise,  any  savings  in  mailing  the  hard  copy  drawings  separa¬ 
tely  would  have  to  be  realized  indirectly  through  a  reduction  in 
SICC  processing  and  wait  time  as  described  above  or  in  IMM  pro¬ 
cessing  and  wait  time  as  described  below. 

( c )  IMM  Initial  Data  Preparation  Processing 


Currently  the  SSR  transactions  and  technical 
data  are  received  together  in  a  package  by  mail.  The  SSR  trans¬ 
actions  must  be  separated  from  the  drawings  and  forwarded  to  data 
processing  operations  for  computer  processing.  The  technical 
data  must  be  filed  in  a  Provisioning  Item  History  Envelop  (PIHE) 
and  filed  while  waiting  for  the  SSR  transactions  to  be  initially 
processed  and  received  back  from  the  computer. 

During  the  AUTODIN  Test  the  SSR  transac¬ 
tions  were  sent  directly  by  AUTODIN  operations  to  computer  opera¬ 
tions  bypassing  the  functional  operations.  The  drawings  were 
either  sent  by  TELEFAX  or  by  mail  separately  from  the  SSR  trans¬ 
actions.  All  technical  data  whether  sent  by  mail  with  SSR  trans¬ 
actions,  separate  from  SSR  transactions  by  mail  or  separately 
from  SSR  transactions  by  TELEFAX  require  the  annotation  of  con¬ 
trol  data  on  the  technical  data.  Regardless  of  which  way  the 
technical  data  is  received,  it  must  subsequently  be  matched  up 
with  SSR  transactions  received  back  from  the  computer. 

When  the  SSRs  were  received  over  AUTODIN, 
there  is  a  savings  in  wait  and  processing  time  in  initial  data 
preparation,  since  the  transactions  do  not  have  to  wait  to  be 
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forwarded  from  the  local  mall  room  to  the  functional  area  and 
await  sorting  out  of  the  transactions  by  the  functional  area  for 
forwarding  to  computer  operations.  It  Is  estimated  that  approxi¬ 
mately  one  week's  internal  processing  and  wait  time  was  saved  by 
forwarding  the  SSR  transactions  directly  from  AUTODIN  operations 
to  computer  operations.  Since  the  transactions  went  from  com¬ 
puter  to  AUTODIN  to  computer  in  most  instances,  there  was  greater 
control  realized  by  elimination  of  manual  processing  and  use  of 
computer  control  of  transactions  from  generation  until  introduc¬ 
tion  into  the  suspense  file  of  the  IMM. 

The  submitter  and  receiver  evaluation  re¬ 
ports  indicated  that  there  were  problems  in  transmitting  and 
receiving  technical  data  over  TELEFAX  due  to  the  interruptions 
experienced  on  the  voice  grade  communications  lines  and  the  time 
to  transmit  and  receive  the  data.  There  was  some  question  as  to 
the  marking  of  control  data  on  the  drawings  sent  by  TELEFAX, 
however,  during  field  research  the  same  problems  were  reported 
for  drawings  that  were  mailed.  The  time  resources  required  to 
submit  and  receive  technical  data  over  TELEFAX  and  the  problems 
experienced  are  a  function  of  the  system  tested  as  opposed  to 
the  concept  of  electrical  transmission  of  technical  data. 

The  technical  data  sent  by  TELEFAX  was 
generally  received  shortly  after  the  receipt  of  the  SSR  transac¬ 
tions  over  AUTODIN  and  almost  always  prior  to  the  requirement  to 
process  the  technical  data.  TELEFAXED  data  that  was  received 
more  than  a  day  or  two  after  the  earliest  used  data  was  late  due 
to  problems  in  transmission  or  was  oversized  drawings.  Even  when 
technical  data  was  mailed  separately  from  the  SSR  transactions  it 
was  generally  received  a  few  days  after  the  requirement  for  its 
initial  use.  It  is  not  known  if  this  Is  a  function  of  the  sub¬ 
mission  and  mail  times  for  the  data  mailed  separately  or  whether 
it  was  a  function  of  the  scheduling  of  the  AUTODIN  submission  of 
SSRs  by  two  of  the  test  submitting  activities. 

(d)  IMM  Validation  Processing.  There  is  no 
direct  savings  in  validation  processing  to  be  realized  due  to  the 
AUTODIN  transmission  of  SSR  transactions  or  the  TELEFAX  of  tech¬ 
nical  data.  However,  there  is  an  indirect  affect  upon  the  timing 
of  the  start  and  completion  of  validation  and  entry  of  the  trans¬ 
action  into  suspense  files.  Due  to  the  savings  in  internal  pro¬ 
cessing  and  wait  time  at  the  SICC,  actual  transmit  time  using 
AUTODIN  and  savings  in  IMM  data  preparation  time  at  the  IMM  by 
direct  routing  from  AUTODIN  operations  to  computer,  the  valida¬ 
tion  processing  can  commence  earlier  than  if  the  transactions  had 
been  mailed.  Since  validation  commenced  earlier  in  time,  reject 
transactions  can  be  returned  earlier  for  correction  and  resubmis¬ 
sion  and  valid  transactions  can  be  processed  to  the  next  step. 
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(e)  Catalog  Data  Screening.  Transactions  that 
pass  validation  are  then  sent  to  DLSC  for  screening;  part  numbers 
to  determine  if  there  is  an  NSN  assigned  and  NSNs  to  verify  the 
NSN  and  obtain  the  latest  catalog  data  on  the  item*  There  is  no 
direct  decrease  in  time  to  perform  this  operation;  however,  this 
function  can  be  performed  earlier  in  time  due  to  the  earlier 
receipt  and  introduction  into  processing.  Transactions  that  are 
sent  back  to  the  SICC  as  a  result  of  DLSC  screening  can  be  re¬ 
turned  earlier  because  the  function  was  commenced  and  completed 
earlier.  Transactions  that  were  not  returned  can  be  introduced 
to  the  next  step  earlier  in  time. 

( f )  Item  Entry  Control 


Transactions  that  do  not  require  item  entry 
control  are  NSNs  and  PSCN  items.  An  NSN  item  can  be  accepted  or 
rejected  right  after  DLSC  screening  and  need  not  be  processed 
through  this  function.  PSCN  items  can  be  sent  directly  for  NSN 
request  and  assignment.  Part  numbered  items  for  which  no  tech¬ 
nical  data  will  be  provided  can  be  directly  introduced  into  this 
function  if  a  proper  item  name  has  been  supplied.  There  is  an 
indirect  reduction  in  processing  time  for  these  items  attribu¬ 
table  to  the  earlier  start  through  this  process  achieved  by  reduc 
tlons  in  transmission  time  and  elimination  or  reduction  in  other 
processing  activities  at  the  SICC  or  in  data  preparation  at  the 
IMM. 


Items  for  which  technical  data  was  supplied 
and  was  sent  by  TELEFAX  was  usually  received  prior  to  the  receipt 
of  the  part  number  select  list  used  to  commence  item  entry  con¬ 
trol.  However,  the  quality  of  the  technical  data  received  over 
the  TELEFAX  system  was  not  always  adequate  in  terms  of  legibility 
to  be  sufficient  to  use  for  item  entry  control,  item  identifica¬ 
tion,  NSN  assignment  purposes,  or  for  subsequent  entry  into  the 
technical  data  library.  The  receiving  test  activity  estimates 
that  about  50-60%  were  usable  for  item  entry  control  and  item 
Identification;  90%  for  NSN  request  and  assignment  and  only  about 
2%  were  considered  usable  for  entry  into  the  technical  data 
library.  As  a  result  of  the  review  of  the  input  and  output  pro¬ 
ducts  from  the  TELEFAX  system  and  an  analysis  of  the  evaluation 
report  submitted  by  the  test  receiver,  it  is  concluded  that  the 
"system  as  tested,"  while  resulting  in  a  significant  reduction  in 
submission/transmission  time,  does  not  provide  a  product  of  suf¬ 
ficient  quality  to  be  usable  by  the  IMM.  For  those  items  with 
usable  technical  data  received  by  electrical  transmission,  a 
significant  reduction  in  total  SSR  processing  time  can  be  real¬ 
ized.  However,  the  quality  of  the  image  received  should  approach 
library  quality  legibility  to  cause  a  significant  improvement  in 
technical  operations  functions. 
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It  should  be  noted  that  even  when  drawings 
were  mailed,  they  were  sometimes  received  shortly  after  receipt 
of  the  part  number  select  list.  There  appears  to  be  a  potential 
for  Indirect  savings  In  overall  processing  time  If: 

*  The  hard  copy  drawings  could  be  properly  marked  with  con¬ 
trol  data  and  mailed  earlier  by  the  SICC. 

*  Aperture  cards  were  sent  by  higher  priority  mail  so  that 
they  could  be  received  earlier  in  the  cycle. 


The  general  consensus  of  the  test  activi¬ 
ties  was  that  the  concept  of  electrical  transmission  of  technical 
data  did  introduce  a  greater  element  of  control  and  should  be 
explored  further  by  testing  other  techniques  to  see  if  the  trans¬ 
mission  time,  ease  of  operator  functions  could  be  simplified  on 
the  submitting  and  receiving  ends,  and  the  quality  of  the  trans¬ 
mitted  image  could  be  improved.  Transmitters  of  technical  data 
via  mall  also  Indicated  an  improvement  in  operations  by  separa¬ 
tely  mailing  the  technical  data.  The  receiving  activity  indi¬ 
cated  problems  in  matching  technical  data  with  SSR  output  because 
control  data  was  not  always  annotated  on  the  technical  data. 
Actually  since  the  matching  of  technical  data  with  SSRs  is  elimi¬ 
nated  at  the  SICC,  the  sorting  out  of  SSRs  from  technical  data  is 
eliminated  at  the  IMH,  and  the  technical  data  must  be  temporarily 
filed  and  matched  with  the  part  number  select  items  anyway,  there 
is  a  potential  for  improvement  in  the  system  by  mailing  the  tech¬ 
nical  data  separately  from  SSR  transactions,  if  the  technical 
data  is  properly  marked  with  control  data. 


(g)  Item  Identification,  SSN  Request/Assign¬ 
ment  .  This  activity  can  be  improved  if  technical  data  in  the 
form  of  descriptive  technical  data  or  an  item  name  can  be  pro¬ 
vided  with  the  SSR  transaction  or  prior  to  the  time  for  commence¬ 
ment  of  this  action.  The  minimum  data  required  for  assignment 
of  a  stock  number  is  a  valid  item  name  in  addition  to  the  refer¬ 
ence  number.  Item  name  should  always  be  provided  with  part  num¬ 
bered  items.  It  is  required  to  be  provided  either  in  technical 
data  itself  or  in  the  form  of  an  item  name  card.  Some  systems 
generate  an  item  name  card  for  all  items  and  pull  it  if  technical 
data  is  supplied.  There  does  not  appear  to  be  any  reason  why 
item  name  cannot  always  be  supplied  with  the  SSR  transaction  sub¬ 
mission  though  additional  technical  data  is  supplied.  If  item 
name  were  always  provided  in  the  SSR  transaction  about  3.3Z  of 
the  rejects  could  be  eliminated.  If  the  item  names  were  always 
supplied  stock  numbering  action  and  supply  support  could  proceed 
and  technical  data  received  later  could  be  used  to  upgrade  the 
item  identification. 
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(h)  IMM  Advice  Processing*  Advice  processing 
and  submission  is  a  function  of  the  other  activities  described 
above.  To  the  extent  the  other  activities  are  completed  sooner, 
advice  can  be  transmitted  sooner.  Use  of  AUTODIN  to  transmit  the 
advice  will  decrease  actual  transmission  time. 

(i)  SICC  Advice  Processing.  A  decrease  in  the 
time  for  a  SICC  to  receive  and  process  advice  is  a  function  in  a 
decrease  in  the  times  for  prior  activities  and  events.  To  the 
extent  that  the  times  for  prior  activities  and  events  are  de¬ 
creased,  there  will  be  a  net  decrease  in  the  time  when  advice  is 
received  and  processed  by  the  SICC. 

I .  SUMMARY  ANALYSIS,  CONCLUSIONS  AND  RECOMMENDATIONS 
1 .  Analysis  and  Conclusions 

The  sum  total  research  by  the  DODSSR  Study  Team  including 
system  design  review,  operational  Implementation  review,  data 
collection  and  analysis,  and  the  AUTODIN/TELEFAX  Test  clearly 
indicated  the  advantage  of  electrically  transmitting  SSR  transac¬ 
tions  that  do  not  require  technical  data  over  AUTODIN.  This 
includes  the  following  categories  of  items: 

Items  with  stock  numbers. 

Permanent  system  control  number  items. 

Part  number  items  for  which  technical  data  is  not 
required  or  will  not  be  supplied. 

The  advantages  of  submitting  technical  data  electrically 
can  be  realized  only  if  the  data  can  be  easily  and  rapidly  trans¬ 
mitted  with  the  received  image  being  of  a  quality  that  approaches 
the  requirements  for  entry  into  the  technical  data  library.  The 
TELEFAX  system  tested  did  not  meet  these  requirements,  but  the 
concept  of  electrical  transmission  has  potential  and  should  be 
continued  to  be  explored. 


The  advantages  of  mailing  technical  data  while  sending 
the  SSR  transaction  over  AUTODIN  are  not  so  obvious  as  the  case 
for  those  items  not  requiring  technical  data.  However,  there 
appears  to  be  a  potential  for  a  decrease  in  total  processing  time 
as  well  as  an  increase  in  control  if  the  technical  data  is  pro¬ 
perly  marked  with  control  data,  at  a  minimum  with  the  PCC,  ISN, 
and  submitting  activity,  and  submitted  as  early  as  possible  by  the 
SICC,  including  the  consideration  of  mailing  the  technical  data 
after  potential  SSR  candidates  are  known,  but  prior  to  generation 
of  the  SSR  transaction.  The  item  name  should  be  supplied  with 
the  SSR  transaction.  A  method  of  following  up  for  technical  data 


should  be  established  and  a  management  report  developed  to  show 
Information  pertaining  to  the  instance  of  items  where  technical 
data  was  received  when  required,  frequency  of  followups,  response 
to  follow  ups  and  final  technical  data  received.  Goals  should  be 
established  and  a  copy  of  the  report  should  be  provided  by  the 
IMM  to  each  of  the  SICCs  in  order  to  monitor  and  control  the  pro¬ 
cess.  As  a  corollary  action  a  definition  and  purpose  of  tech¬ 
nical  data  should  be  reviewed  snd  requirements  for  technical  data 
for  the  following  uses  should  be  established: 

Selection  of  maintenance  significant  items. 

Item  entry  control. 

Catalog  identification. 

-  Purchase  description. 

2.  Recommendations .  The  SSR  procedures  and  systems  should 
be  revised  in  accordance  with  the  following  recommendations. 

a.  All  supply  support  requests  for  which  technical  data 
is  not  required  should  be  sent  over  AUTODIN  using  the  most  direct 
interface  between  computer  operations  and  AUTODIN  operations 
available  at  the  sending  and  receiving  activities.  Item  name 
information  should  be  provided  for  all  items  forwarded  over 
AUTODIN.  An  early  implementation  date  should  be  provided  for 
this  recommendation  since  it  can  be  easily  implemented  by  all 
activities  possessing  AUTODIN  terminals. 

b.  Procedures  and  systems  at  SICCs  and  IMMs  should  be 
revised  to  transmit  SSR  part  numbered  items  for  which  technical 
data  is  required  and  available  over  AUTODIN  with  the  technical 
data  marked  with  control  data  submitted  as  soon  as  SSR  candidates 
are  selected. 

c.  A  followup  and  reporting  procedure  should  be  estab¬ 
lished  to  monitor  and  control  the  transmission  and  receipt  of 
technical  data.  A  procedure  for  following  up  for  technical  data 
should  be  established.  A  management  report  should  be  developed 
to  provide  goals  for  the  receipt  of  technical  data  and  to  monitor 
and  control  its  receipt. 

d.  The  definition  and  purpose  of  technical  data  should 
be  reviewed  and  requirements  established  for  its  acquisition,  use 
and  retention  for  the  following  categories  of  usage: 

*  Selection  of  maintenance  significant  items. 

*  Item  entry  control. 

*  Catalog  identification. 

*  Purchase  description. 
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e.  Assign  a  study  to  the  Defense  Logistics  Analysis 
Office  to  determine  the  feasibility  of  scanning  technical  data  at 
one  geographic  location,  converting  the  graphic  data  to  an  elec¬ 
trical  or  electronic  signal  and  transmitting  the  signal  to  another 
geographic  location  to  be  converted  to  an  Image  or  facsimile  of 
the  input  document  of  sufficient  quality  to  be  used  for  technical 
operations  functions  and  retention  in  a  technical  data  library 
repository . 


CHAPTER  III 


EDIT/VALIDATION  ANALYSIS  ) 

! 


A.  INTRODUCTION  ] 

-  i 

■i 

1.  General .  The  Special  Projects  Group  (SPG)  for  Provi-  j 

sioning  cited  an  excessive  number  of  rejected  SSR  transactions  ! 

as  one  of  the  major  problems  in  initiating  the  DODSSR  Study. 

This  problem  in  conjunction  with  other  SPG  reported  problems  was  j 

researched  during  the  SDA  and  SICC/IMM  activity  visits  made  by  j 

the  study  team.  These  activity  visits  led  to  several  observa-  j 

tions  that  warranted  further  research.  First,  SSRs  were  being  ■ 

rejected  for  several  reasons  of  which  invalid  data  was  only  one  ] 

category.  Second,  each  of  the  Services/Agencies  were  generally 
including  automated  validation  of  SSR  data  elements  as  part  of  j 

their  SSR  Systems  Design.  Third,  some  data  elements  were  being  j 

edited  when  found  to  be  invalid  as  part  of  automated  SSR  systems  j 

design.  Finally,  the  validations  and  application  of  validation 
reject  codes  differed  significantly  on  an  inter/intra  Component 
basis  for  incoming  and  outgoing  SSR  transactions. 

2.  Purpose .  Preliminary  analysis  of  SSR  transactions  from 
the  DODSSR  data  collection  showed  a  significant  number  of  rejects 
due  to  invalid  data.  The  study  team  concluded  the  reason  for 
many  of  these  validation  rejects  was  conversion  from  the  old  SSR 
procedures  and  formats  to  those  contained  in  the  IMM  Manual  and 
to  the  varying  amount  of  manual  vs.  automated  processing  done  by 
the  different  Components.  This  Chapter  analyzes  the  manual  vali¬ 
dations  performed  by  the  Components  and  the  validations  contained 
in  the  automated  SSR  systems  design  of  each  Component  (whether 
implemented  or  not)  to  determine  if  validation  of  SSRs  will  be 
compatible  upon  implementation  of  the  designed  systems  or  if 
some  standardized  validation  criteria  must  be  developed  to  re¬ 
duce  the  occurrence  of  validation  rejects. 

3.  Methodology .  During  the  operational  implementation  re¬ 
view  at  SICC/IMM  activities,  the  manual  validations  being  per¬ 
formed  were  researched  to  the  satisfaction  of  the  study  team. 

However,  due  to  the  variability  in  automated  design  concept, 
design  development,  documentation  availability,  and  implementa¬ 
tion  status,  the  study  team  found  additional  research  was  neces¬ 
sary  to  perform  the  required  validation  analysis.  This  led  to 
the  development  of  a  validation  analysis  questionnaire  and  a 
validation  test  as  additional  tools  for  the  analysis.  After 
coordination  with  the  SPG  and  Individual  Component  contact 
points,  the  validation  analysis  questionnaire  was  mailed  to  each 
Component  System  Design  Activity  for  completion.  The  validation 
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test  was  mailed  to  each  Component  System  Design  Activity  or 
alternate  activity  to  be  executed  using  operational  automated 
validation  program  modules. 


a .  Validation  Analysis  Questionnaire 

The  validation  analysis  questionnaire  was  developed 
from  the  general  findings  from  field  research  and  the  available 
documentation  provided  by  the  system  design  activities.  The 
automated  systems  designs  were  found  to  contain  multiple  vali¬ 
dation  program  modules,  multiple  levels  of  validation  and  vary¬ 
ing  detailed  data  element  validation  within  levels.  Five  dif¬ 
ferent  levels  of  validation  were  found  to  exist.  These  levels 
include  a  package  validation  level,  a  match/duplicate  validation 
level,  a  control  data  element  validation  level,  a  key  data  ele¬ 
ment  validation  level  and  a  detail  data  element  validation 
level.  The  package  validation  level  generally  includes  valida¬ 
tions  for  PCC  package  and  line  item  package  combinations.  The 
match/duplicate  level  generally  includes  a  check  for  duplicate 
submittals  in  the  same  processing  cycle  and  a  match  of  advice 
and  SSR  change  transactions  against  the  automated  SSR  Suspense 
File  to  Insure  a  valid  SSR  transaction  exists  on  the  file.  Con¬ 
trol  data  elements  are  those  used  for  sequencing  of  transactions, 
controlling  the  flow  of  transactions  or  retrieval  of  previously 
submitted  SSR  data.  Key  data  elements  are  those  in  addition  to 
control  data  elements  required  to  process  an  SSR  transaction; 
e.g.,  NSN .  Detail  data  element  validation  is  done  on  the  re¬ 
mainder  of  data  elements  in  each  SSR  transaction.  It  is  within 
detail  data  element  validation  that  editing  of  invalid  data  ele¬ 
ments  takes  place. 

The  validation  analysis  questionnaire  consisted  of  a 
series  of  questions  to  be  answered  and  matrices  to  be  completed 
to  provide  Component  equivalent  information  on  the  number  and 
type  of  validation  program  modules,  the  levels  within  each  pro¬ 
gram  module,  the  hierarchy  of  these  levels,  the  specific  criteria 
and  validation  reject  codes  used  in  each  level  and  validation 
techniques  used  by  each  Component.  Both  the  Marine  Corps  and 
GSA  were  in  early  stages  of  system  design  at  the  time  of  ques¬ 
tionnaire  dissemination.  Therefore  these  Components  were  not 
asked  to  complete  this  questionnaire. 

Preliminary  analysis  of  the  questionnaire  indicated 
widely  varying  validation  conventions  and  criteria  among  the 
Components.  This  led  the  study  team  to  develop  a  set  of  valida¬ 
tion  criteria  based  on  the  questionnaire  and  the  study  team's 
literal  interpretation  of  the  intent  of  the  IMM  Manual.  This 
validation  criteria  was  applied  to  the  DODSSR  data  base  to  deter¬ 
mine  the  potential  for  development  of  standardized  validation 
criteria  and  is  discussed  below. 
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b.  Validation  Test .  As  an  additional  method  of  docu¬ 
menting  the  validation  conventions  and  criteria  being  used  for 
use  by  the  study  team  in  analysis,  the  study  team  developed 
three  EAM  card  decks  of  test  data.  Each  deck  contained  a  series 
of  valid  and  invalid  PDSSR,  L1SSR,  and  LIAC  transactions.  One 
deck  was  designed  to  be  used  by  each  of  the  Services  as  a  test 
of  outgoing  validation  concepts  and  criteria.  The  second  deck 
was  designed  to  be  used  by  each  of  the  Services  as  a  test  of 
Incoming  WIMM  validation  concepts  and  criteria.  The  third  deck 
was  designed  to  be  used  by  the  Army  and  DLA  as  a  test  of  incoming 
CIMM  validation  concepts  and  criteria.  As  with  the  validation 
analysis  questionnaire,  the  validation  test  was  not  given  to  the 
Marine  Corps  and  CSA  because  of  the  early  stage  of  their  auto¬ 
mated  systems  development.  The  study  team  requested  that  each 
deck  be  invit  to  the  Component  automated  SSR  Application  and 
that  all  normal  outputs  as  well  as  some  rpecific  file  dumps  be 
provided  the  study  team  for  analysis.  It  was  hoped  that  this 
would  provide  a  basis  for  validation  analysis  and  as  a  byproduct 
some  Insight  into  the  types  of  automated  outputs  normally  fur¬ 
nished  to  the  functional  user.  The  responses  from  the  Components 
ranged  from  completion  of  the  test  as  requested  to  no  response. 
Since  this  did  not  provide  a  consistent  basis  for  analysis,  the 
validation  test  results  were  not  used  as  a  basis  for  the  valida¬ 
tion  analysis  contained  in  this  Chapter. 

c .  DODSSR  Validation  Criteria 

As  stated  above,  the  preliminary  review  of  the  com¬ 
pleted  questionnaires  showed  that  validation  conventions  and 
even  the  criteria  for  some  data  elements  varied  widely  from  Com¬ 
ponent  to  Component.  This  variation  includes  sequence  of  data 
element  validation,  multiple  vs  single  error  identification,  and 
internal  error  code  usage  as  three  examples.  Many  of  these  con¬ 
cepts  appeared  to  have  merit  and  were  designed  to  counteract 
some  problems  reported  to  the  study  team  during  the  activity 
visits.  One  of  these  problems  was  that  SSR  transactions  were 
submitted  to  an  IMM  and  rejected  for  a  validation  error.  These 
SSR  transactions  were  then  corrected  and  resubmitted  by  the  SICC 
only  to  be  rejected  for  a  different  validation  error.  Another 
problem  reported  was  that  some  reject  codes  (ATCs)  were  not  spe¬ 
cific  enough  in  identifying  the  data  element  in  error.  The  most 
notable  of  these  codes  are  '52'  (Mandatory  PDSSR  Data  Missing) 
and  ’32’  (Mandatory  USSR  Data  Missing). 

To  show  the  effect  of  these  conventions  on  the  sys¬ 
tem  as  a  whole  and  to  test  the  feasibility  for  standardization 
by  all  Components,  the  study  team  developed  the  DODSSR  Valida¬ 
tion  Criteria.  This  criteria  was  incorporated  into  a  data  pro¬ 
cessing  specification,  and  computer  programs  were  developed  and 
applied  to  the  DODSSR  data  base.  A  series  of  analytical  reports 


were  generated  from  the  results  of  this  validation  for  use  in  a 
comparative  analysis  of  validation  conventions  and  criteria  in 
conjunction  with  the  validation  analysis  questionnaire* 

4.  Definitions .  There  are  five  terms  used  repeatedly  in 
the  chapter  to  describe  and  analyze  the  editing  and  validating 
performed  by  the  Components  and  applied  to  the  DODSSR  data  base* 
These  are: 

-  Edit 

-  Validate 

-  Validation  Level 

-  Validation  Hierarchy 

-  Validation  Conventions 

These  terms  are  defined  here  to  provide  a  basis  of  understanding 
the  information  contained  in  this  chapter. 

a.  Edit.  To  modify  or  delete  invalid  data,  generally 
as  the  result  of  validation,  to  allow  a  transaction  to  pass  to 
the  next  sequential  operation  and  to  preclude  rejection  of  the 
transaction  due  to  the  invalid  data. 

b.  Validate .  To  check  data  for  correctness  and  compli¬ 
ance  with  prescribed  standards,  rules  and  formats. 

c.  Validation  Level.  A  validation  level  consists  of 
all  data  checks  equal  in  importance  rank  or  degree  and  occupying 
equivalent  positions  on  a  scale  of  validation  criteria. 

d.  Validation  Hierarchy.  A  validation  hierarchy  con¬ 
sists  of  all  validation  levels  performed  ranked  in  order  of  per- 
f  ormance . 

e.  Validation  Conventions.  A  validation  convention  con¬ 
sists  of  the  valiation  hierarchy,  validation  levels,  validation 
structure,  validation  sequence,  and  any  other  validation  concepts 
used  other  than  the  specific  validation  criteria  itself. 

B.  MANUAL  EDIT/VALIDATIONS 

1.  General .  The  manual  validations  performed  by  each  Com¬ 
ponent  were  presented  in  Volume  II.  The  specific  data  elements 
validated  are  repeated  here  to  refresh  the  reader's  memory  of 
these  validations  and  to  allow  easier  reference  for  comparison 
with  automated  validations  presented  later  in  this  Chapter. 

2 .  Army 

a.  Outgoing  provisioning  and  nonprovisioning  SSR  trans¬ 
actions  are  not  formally  validated.  When  an  error  condition  is 


encountered  on  outgoing  PDSSR,  LISSR,  or  LIAC  transactions  during 
routine  processing;  the  error  condition  is  corrected  prior  to 
transmission  of  the  SSR  transaction. 

b.  Incoming  WIMM  SSR  transactions  are  manually  validated 
for  proper  entries  in  the  following  data  elements. 

Provisioning  Control  Code 
Activity  Code  To 
Activity  Code  From 
Date  of  Request 
Item  Serial  Number 
Retail  Quantity 
Replenishment  Quantity 

When  an  error  is  encountered  in  one  or  more  of  these  data  ele¬ 
ments,  the  SICC  is  contacted  by  telephone  to  obtain  the  correct 
Information  which  is  then  used  in  lieu  of  the  information  sub¬ 
mitted  on  the  SSR  transaction.  LIACs  responding  to  these  SSR 
transactions  are  manually  generated  and  are  not  validated. 

c.  Incoming  CIMM  SSR  transactions  are  manually  validated 
by  type  of  SSR  transaction.  PDSSR  data  elements  validated  in¬ 
clude  : 

Document  Identifier  Code 
Date  Repair  Parts  Required 
Provisioning  Control  Code 
Activity  Code  From 
End  Item  Name,  NSN,  etc. 

Number  of  SSRs  Enclosed 

LISSR  data  elements  validated  Include: 

Document  Identifier  Code 
Retail  Quantity 
Replenishment  Quantity 
Production  Leadtime 

Catalog  transactions  are  validated  for  proper  Document  Identifier 
Code  only.  Corrections  are  made  to  invalid  transactions  received 
based  on  telephone  communication  with  the  SICC.  LIACs  are  not 
specifically  validated  and  errors  on  these  transactions  are  iden¬ 
tified  during  routine  processing. 

3 .  Navy 

a.  Outgoing  provisioning  and  nonprovisioning  SSR  trans¬ 
actions,  and  related  LIACs  are  not  subjected  to  a  separate  vali¬ 
dation  processing  step.  These  transactions  may  be  found  to  be 
in  error  during  routine  processing,  and  if  so,  are  corrected. 
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b.  Incoming  SSR  transactions  are  subjected  to  minimal 
validation.  Generally  only  control  elements  such  as  Provisioning 
Control  Code  and  Activity  Code  To  are  routinely  checked  for 
proper  entries. 

4.  Air  Force 


a.  There  is  no  manual  validation  of  outgoing  SSR  trans¬ 
actions  in  the  Air  Force. 

b.  Incoming  PDSSR  and  LISSR  transactions  are  examined 
for  proper  package  content.  Specific  data  elements  validated 
Include : 

Provisoning  Control  Code 
Date  of  Request 
Retail  Quantity 
Replenishment  Quantity 
Unit  Price 
End  Item  Quantity 

When  errors  are  encountered  in  any  or  all  of  these  data  elements, 
the  SICC  is  telephonically  contacted  to  determine  the  correct 
entries.  The  invalid  SSR  transactions  are  then  corrected  prior 
to  entering  them  into  the  automated  SSR  Application.  Advice 
transactions  are  not  manually  validated. 

5 .  Marine  Corps 


a.  There  is  no  separate  validation  of  outgoing  PDSSR, 
LISSR  or  LIAC  transactions.  When  errors  are  encountered  during 
routine  processing,  they  are  corrected  before  processing  con¬ 
tinues  . 


b.  Incoming  SSR  transactions  are  not  validated  separately 
by  the  Marine  Corps.  As  with  outgoing  transactions,  errors  are 
identified  during  the  normal  course  of  processing.  When  an  error 
condition  is  encountered,  the  SICC  is  notified  of  the  error  via 
LIAC  with  an  appropriate  reject  code. 

6.  DLA .  DLA  procedures  do  not  provide  for  manual  validation 
of  SSR  transactions. 

7.  GSA .  When  SSRs  are  received  they  are  validated  for  pro¬ 
per  package  content  and  the  submitted  Federal  Supply  Classifica¬ 
tion  (FSC)  in  Part  Number  SSRs  is  checked  to  ensure  it  is  an  FSC 
managed  by  GSA.  Other  errors  may  be  identified  during  routine 
processing.  The  SICC  is  notified  of  errors  via  manual  genera¬ 
tion  of  LIACs  with  an  appropriate  reject  code. 
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C.  AUTOMATED  EDIT/VALIDATIONS 


1 .  General 

This  section  discusses  the  automated  validation  performed 
on  SSR  transactions  and  related  validation  conventions  which  de¬ 
tail  the  validation  concepts  designed  by  each  of  the  Components. 
These  validation  concepts  are  discussed  first  on  a  Component  by 
Component  basis.  This  is  followed  by  a  presentation  of  the 
detailed  validation  criteria  on  a  data  element  basis. 

The  discussion  of  automated  validation  conventions  and 
criteria  is  limited  to  the  Army,  Navy,  Air  Force,  DLA,  and  the 
validation  developed  by  the  DODSSR  Study  Team.  The  validation 
to  be  included  in  the  automated  systems  design  of  the  Marine 
Corps  has  not  been  sufficiently  developed  and  documented  to 
allow  inclusion.  The  validation  concepts  designed  by  GSA  are 
contained  in  their  detailed  systems  design  specification.  This 
specification  was  furnished  to  the  study  team  subsequent  to 
completion  of  the  validation  analysis  questionnaire  by  the  other 
Components.  The  GSA  validation  criteria  is  therefore  not  specif¬ 
ically  Included  in  the  analysis;  however,  a  discussion  of  GSA 
validation  concepts  is  included.  In  addition,  review  of  the  GSA 
validation  criteria  indicates  it  is  consistent  with  that  of  the 
other  Components. 

2 .  Validation  Conventions 


a .  Army 


( 1 )  Program  Structure 


The  Army  design  includes  validation  as  part  of 
three  program  modules  shown  in  Figure  II-4,  Volume  II,  Part  1, 
Chapter  II.  The  SSR  converter  program  module  receives  outgoing 
SSR  candidates  in  random  sequence  from  the  Army  Automated  Require¬ 
ments  Determination  Application.  These  candidates  are  validated 
for  proper  ite»#  identification,  MOE  Rule,  Activity  Code  and  Man¬ 
ager  data.  These  candidates  are  also  checked  to  insure  they  are 
consumable  items.  Valid  candidates  are  formatted  into  SSR  trans¬ 
actions  which  are  posted  to  the  Army  SSR  Suspense  File  and  punched 
in  E AM  cards  in  subsequent  program  modules.  Rejected  candidates 
are  appended  with  an  Army  unique  reject  code  and  passed  to  the 
Army  Standard  Reject  Control  Application  for  printing  and  manual 
action.  Although  these  transactions  pass  through  other  valida¬ 
tion  program  modules  before  being  posted  to  the  SSR  Suspense  File 
and  punched  in  EAM  cards;  they  generally  do  not  undergo  further 
detail  data  element  validation.  The  philosophy  behind  this  is 


that  these  SSR  transactions  are  mechanically  generated  from  data 
resident  on  automated  provis ' oning  files  and  the  local  TIR  file. 
This  data  is  subjected  to  extensive  validation  before  being 
entered  on  these  files  and  thus  does  not  require  further  valida¬ 
tion. 


The  SSR  Edit  and  Validation  program  module 
receives  transactions  from  the  SSR  Converter  program  module  and 
manually  input  transactions.  Manually  input  transactions  in¬ 
clude  manually  generated  outgoing  SSR  transactions,  incoming  SSR 
transactions,  and  both  outgoing  and  incoming  LIACs.  These  trans¬ 
actions  are  sorted  into  Provisioning  Control  Code,  Activity  Code 
To,  Activity  Code  From,  Date  of  Request,  Item  Serial  Number, 
Document  Identifier  Code,  and  Card  Number  sequence  prior  to  entry 
into  this  program  module.  Transactions  from  the  SSR  Converter 
program  module  are  bypassed;  all  other  transactions  are  validated 
Transactions  are  validated  until  the  first  error  is  encountered 
and  invalid  transactions  are  assigned  an  Army  unique  reject  code. 
This  program  module  does  no  file  recording. 

The  SSR  File  Maintenance  program  module  receives 
the  same  transactions  in  the  same  sequence  as  those  received  by 
the  SSR  Edit  and  Validation  program  module.  This  program  module 
validates  input  transactions  against  the  SSR  Suspense  File  for 
duplicate/match/nonmatch  conditions.  All  valid  transactions  and 
some  invalid  transactions  are  posted  to  the  SSR  Suspense  File  by 
this  program  module.  Invalid  transactions  not  posted  include 
duplicate  transactions,  advice  transactions  with  no  matching 
LISSR  transaction  on  the  SSR  Suspense  File,  and  transactions 
with  Control  Data  Element  or  Key  Data  Element  Errors.  Invalid 
transactions  identified  in  the  program  module  are  assigned  an 
Army  unique  reject  code. 

The  SSR  application  automatically  generates 
some  advice  transactions.  Those  generated  by  this  application 
are  not  validated  prior  to  either  punching  in  EAM  cards  or  being 
transferred  to  magnetic  tape  for  AUTODIN  transmittal. 

( 2 )  Validation  Levels 


The  Army  SSR  Application  has  all  five  levels  of 
validation  imbedded  in  it.  Only  the  SSR  Edit  and  Validation 
program  module  uses  all  five  levels.  The  SSR  Converter  program 
module  does  detail  data  element  validation  on  selected  data  ele¬ 
ments  as  discussed  above.  The  SSR  File  Maintenance  program 
module  performs  match/duplicate  level  validations  only.  The 
match/duplicate  validations  performed  by  this  program  module 
Include : 


*  An  initial  submission  SSR  is  checked  against 
the  SSR  Suspense  File  for  matching  control  elements.  If  a  match 
is  found,  the  SSR  is  rejected  as  a  duplicate. 
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*  Each  SSR  change  tran8action  Is  checked  against 
the  SSR  Suspense  File  for  matching  control  elements.  If  no  match 
is  found  the  SSR  is  rejected  as  invalid. 

*  Each  manually  generated  outgoing  LIAC  and  all 
incoming  LIACs  are  matched  against  the  SSR  Suspense  File  for 
matching  control  elements.  If  no  match  is  found,  the  LIAC  is 
rejected  as  Invalid.  The  exception  to  this  is  incoming  follow¬ 
ups  which  are  not  rejected  when  no  match  is  found;  a  No  Record 
followup  response  transaction  is  prepared  for  transmission  to 
the  SICC  when  this  occurs. 

The  hierarchy  of  validation  levels  in  the  SSR 
Edit  and  Validation  program  module  is  package  validation,  match 
duplicate  validation,  control  data  element  validation,  key  data 
element  validation,  and  detail  data  element  validation.  A  PCC 
package  validation  is  performed  first  and  consists  of  a  check 
for  each  PDSSR  transaction  with  Type  Change  Code  (TCC)  *  'N'  or 
'V*  to  ensure  it  is  accompanied  by  one  or  more  LISSR  transactions 
with  TCC  *  blank  or  ’V'  respectively.  Army  validation  allows 
for  a  PDSSR  transaction  with  TCC  ■  'P'  to  be  submitted/received 
without  accompanying  LISSR  transactions.  Other  package  valida¬ 
tions  performed  include: 

*  Each  part  number  SSR  submittal  must  consist 
of  a  card  1  and  card  2. 

*  Each  CXB  card  number  2  having  a  Document 
Availability  Code  (DAC)  *  *2*  or  ’4’  or  ’6’  must  be  accompanied 
by  an  Item  Name  Transaction  (CXF)  with  identical  control  elements 
(except  Document  Identifier  Code  (DIC)). 

*  Each  Item  Name  Transaction  (CXF),  Additional 
Reference  Number  Transaction  (CXG)  and  Additional  User  Transac¬ 
tion  (CXK)  must  accompany  a  LISSR  transaction  with  identical 
control  elements  (except  DIC). 

A  duplicate  check  is  made  on  input  transactions  for  identical 
control  data  elements  on  two  or  more  transactions.  When  this 
occurs,  the  first  transaction  continues  processing  and  the  re¬ 
maining  transactions  are  rejected  as  invalid.  A  check  is  also 
made  against  the  SSR  Suspense  File  for  transactions  with  iden¬ 
tical  control  elements,  if  a  match  is  encountered,  the  transac¬ 
tions  on  file  are  purged  and  the  new  transactions  continue  pro¬ 
cessing.  The  data  elements  specified  as  control  data  elements 
Include  Document  Identifier  Code  (DIC),  Provisioning  Control 
Code  (PCC),  Activity  Code  To  (ACT),  Activity  Code  From  (ACF), 

Item  Serial  Number  (ISN),  Date  of  Request  (DOR),  and  Type  Change 
Code  (TCC).  Key  data  elements  include  End  Item  Name,  NSN,  PSCN, 
Manufacturers  Reference  Number/FSCM  and  Item  Name. 
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All  other  data  elementa  are  considered  detail  data  elements  by 
the  Army.  Specific  validation  criteria  for  control  data  ele¬ 
ments,  key  data  elements  and  detail  data  elements  is  given  in 
the  Detail  Validation  criteria  paragraph  below. 

b.  Navy .  The  Navy  SSR  systems  design  totally  separates 
outgoing  SSR  transaction  processing  from  incoming  SSR  transaction 
processing  as  stated  in  Volume  II,  Part  I.  Incoming  transactions 
are  processed  in  separate  program  modules,  in  a  separate  job 
stream,  and  stored  on  a  separate  automated  file.  Since  these 
transactions  are  handled  separately,  the  validation  conventions 
for  outgoing  SSR  transactions  are  presented  first  followed  by  the 
conventions  for  incoming  SSR  transactions. 

( 1 )  Outgoing  SSR  Transactions 


(a)  Program  Structure 


Outgoing  SSR  transactions  are  validated  in 
three  of  the  five  program  modules  shown  in  Figure  III-6,  Volume 
II,  Part  1,  Chapter  III.  These  are  the  Program  Data  Record  (PDR) 
Update,  SICC  SSR  Validation  and  SICC  SSR  File  Maintenance  Program 
Modules.  The  PDR  Update  program  module  receives  manually  gener¬ 
ated  PDSSR  transactions  in  random  sequence.  These  transactions 
are  validated  prior  to  sorting  them  into  PCC  sequence  for  entry 
to  the  PDR  File.  Valid  transactions  are  entered  on  the  PDR 
File.  Invalid  transactions  are  assigned  a  Navy  unique  error 
code  and  output  for  correction. 


SSR  transactions  input  to  the  SICC  SSR 
Validation  Program  Module  are  first  sorted  into  PCC,  ACT,  ISN, 
DOR,  DIC  and  Card  Number  sequence.  All  transactions  input  are 
validated  for  correct  entries  in  all  data  elements.  Invalid 
transactions  with  a  single  error  are  assigned  an  appropriate 
Navy  unique  reject  code.  Invalid  transactions  with  multiple 
errors  are  assigned  reject  code  'V.'  No  file  recording  is  per¬ 
formed  by  this  program  module. 


The  SICC  SSR  File  Maintenance  Program 
Module  receives  input  SSR  transactions  in  PCC,  ACT,  ISN,  DOR, 
DIC,  Card  Number  sequence.  This  program  module  validates  trans¬ 
actions  against  the  SICC  SSR  Suspense  File.  Invalid  transac¬ 
tions  are  not  posted  to  the  SICC  SSR  Suspense  File,  but  have  the 
data  elements  in  error  blanked  out  in  these  transactions.  These 
transactions  are  output  for  manual  correction.  All  valid  trans¬ 
actions  are  posted  to  the  SICC  SSR  Suspense  File. 


The  outgoing  portion  of  the  Navy  SSR  Appli¬ 
cation  generates  offer  reply  transactions  and  followup  transac¬ 
tions  automatically.  When  a  followup  response  transaction  is 
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received  with  ATC  ■  '66,'  an  initial  submission  SSR  transaction 
is  regenerated  using  SICC  SSR  Suspense  File  data.  These  trans¬ 
actions  are  not  validated  prior  to  outout  for  transmission  to  an 
IMM. 


( b )  Validation  Levels 

The  PDR  Update  Program  Module  performs 
detail  data  element  validation  only.  Each  PDSSR  transaction 
input  is  validated  for  proper  entries  in  DIC  and  TCC. 

The  SICC  SSR  Validation  Program  Module 
performs  detail  data  element  validation  and  package  validation. 
Detail  validation  criteria  is  given  in  the  Detail  Validation 
Criteria  paragraph  below.  Package  validations  performed  on 
outgoing  SSR  transactions  include: 

*  Each  valid  PDSSR  transaction  must  be 
accompanied  by  one  or  more  valid  LISSR  transactions  with  matching 
PCC,  ACT,  and  DOR. 


*  Each  valid  item  name  transaction,  addi¬ 
tional  manufacturer  reference  number  transaction  and  additional 
user  transaction  must  be  accompanied  by  a  valid  LISSR  transac¬ 
tion  with  matching  PCC,  ACT,  ISN  and  DOR. 

*  Each  Part  Number  LISSR  (C/WXB)  must  con¬ 
sist  of  a  valid  Card  Number  1  transaction  and  Card  Number  2 
transaction. 


The  SICC  SSR  File  Maintenance  Program 
Module  performs  mat ch/ dup 1 ic a t e  validations.  Each  input  trans¬ 
action  is  checked  for  a  duplicate  transaction  based  on  matching 
PCC,  ACT,  ISN,  DOR,  DIC  and  Card  Number.  If  duplicate  transac¬ 
tions  are  found,  the  first  continues  processing  and  the  remaining 
transactions  are  rejected  as  invalid.  Outgoing  SSR  change  trans¬ 
actions  and  incoming  advice  (CXI)  and  followup  response  (CX4) 
transactions  are  matched  to  the  SICC  SSR  Suspense  File  on  PCC, 
ACT,  ISN,  and  DOR.  Transactions  for  which  a  match  is  not  found 
are  considered  invalid  and  are  rejected. 

The  outgoing  SSR  validation  described  does 
not  Include  separate  levels  for  control  data  elements  and  key 
data  elements.  Although  the  PCC,  ACT,  ISN,  DOR,  DIC  and  Card 
Number  are  used  for  sequencing  and  control,  they  are  not  iden¬ 
tified  as  control  data  elements  and  are  not  validated  as  a  sepa¬ 
rate  entity  in  detail  data  element  validation. 

(2)  Incoming  SSR  Transactions 

(a)  Program  Structure.  The  WIMM  SSR  Valida¬ 
tion  Program  Module  performs  all  validation  for  incoming  WIMM 
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SSR  transactions.  This  program  module  sorts  all  input  transac¬ 
tions  into  PCC ,  ACF,  00Rt  ISN,  DIC,  TCC  and  Card  Number  sequence 
prior  to  validation.  The  incoming  SSR  system  design  includes 
validation  of  PDSSR,  LISSR  and  Advice  (CXI)  transactions  input 
to  this  program  module.  Validation  of  other  input  LIACs  and 
LIACs  generated  by  this  application  is  not  performed.  Transac¬ 
tions  are  validated  until  the  first  error  is  encountered.  Then 
an  IMM  Manual  reject  code  is  assigned  and  a  reject  advice  trans¬ 
action  is  generated.  Although  this  program  module  performs  no 
file  recording,  the  WIMM  SSR  File  Maintenance  program  module 
posts  both  valid  and  invalid  transactions  to  the  WIMM  SSR  Sus¬ 
pense  File. 


(b)  Validation  Levels.  Within  the  WIMM  SSR 
Validation  program  module  three  distinct  validation  levels  exist. 
A  package  check  is  made  to  ensure  each  PDSSR  transaction  sub¬ 
mitted  is  accompanied  by  a  LISSR  transaction  and  vice  versa.  In 
addition  each  Part  Number  LISSR  (WXB)  Card  Number  1  transaction 
is  checked  to  ensure  it  is  accompanied  by  a  Card  Number  2  LISSR 
transaction  with  the  same  PCC,  ACF,  DOR,  ISN,  DIC  and  TCC.  A 
duplicate  check  is  made  on  each  LISSR  based  on  PCC,  ACF,  DOR, 
and  ISN.  All  duplicates  found  (except  WXB  combinations)  are 
rejected  as  invalid.  The  final  level  of  validation  is  detail 
data  element  validation.  Each  data  element  is  validated  in  turn 
starting  in  card  column  1  and  continuing  through  card  column  80. 
The  specific  detail  data  element  validation  criteria  is  discussed 
below  with  that  of  the  other  Components. 

c .  Air  Force 

( 1 )  Program  Structure 

Air  Force  systems  design  includes  validation  of 
all  incoming  and  outgoing  SSR  transactions  in  the  SSR  Validation 
and  SSR  File  Maintenance  program  modules  of  the  Air  Force  SSR 
Application  shown  in  Figure  IV-5,  Volume  II,  Part  1,  Chapter  IV. 
Input  transactions  are  sorted  into  PCC,  ISN,  Document  Number 
(DOR),  Process  Date,  DIC,  TCC  and  Card  number  sequence  prior  to 
validation. 


The  SSR  Validation  program  module  validates  out¬ 
going  and  incoming  SSR  transactions  for  up  to  six  errors.  After 
the  sixth  error  is  found  the  validation  process  for  that  trans¬ 
action  is  terminated.  For  outgoing  SSR  transactions  in  error, 
a  listing  is  produced  containing  the  invalid  transaction  and  one 
to  six  Air  Force  unique  reject  codes  relating  the  errors  encoun¬ 
tered.  For  incoming  SSR  transactions  in  error,  a  reject  advice 
transaction  containing  an  IMM  Manual  reject  code  (usually  cor¬ 
responding  to  the  first  error  encountered)  is  generated.  This 
program  module  performs  no  file  recording  actions. 


\  -■ 
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The  SSR  File  Maintenance  program  module  also 
performs  validation  on  both  incoming  and  outgoing  SSR  trans¬ 
actions.  This  program  module  will  output  additional  errors  en¬ 
countered  for  outgoing  SSR  transactions  (up  to  the  maximum  of 
six).  This  program  module  posts  all  valid  SSR  transactions 
(except  followups)  to  the  SSR  Suspense  File.  No  invalid  trans¬ 
actions  are  posted  to  this  file. 

The  SSR  Application  in  the  Air  Force  like  those 
of  the  Army  and  Navy  does  generate  SSR  transactions  under  cer¬ 
tain  conditions  as  described  in  Volume  II,  Part  I.  These  trans¬ 
actions  which  are  generated  on  an  automated  basis  are  not  mechan¬ 
ically  validated  prior  to  output  for  transmission  to  another 
activity. 


( 2 )  Validation  Levels 


The  Air  Force  validates  SSR  transactions  at 
three  levels.  These  are  the  package  validation  level,  the  match/ 
duplicate  validation  level  and  the  detail  data  element  valida¬ 
tion  level . 


The  SSR  Validation  program  module  performs  dup¬ 
licate  transaction  validation,  detail  data  element  validation  and 
package  validations  in  that  sequence.  Each  input  transaction  is 
checked  for  a  duplicate  transaction  on  both  a  total  transaction 
and  a  control  data  element  basis.  All  duplicate  transactions  are 
rejected  as  invalid.  The  criteria  for  detail  data  element  vali¬ 
dation  is  described  in  the  following  subparagraph.  The  package 
validations  performed  by  this  program  module  Include: 

*  Each  Part  Number  LISSR  (W/CXB)  must  consist 
of  a  Card  Number  1  transaction  and  a  Card  Number  2  transaction. 

*  Each  LISSR  transaction  containing  TCC  ■  'R' 
must  be  accompanied  by  a  LISSR  transaction  with  matching  control 
elements  having  TCC  ■  'S.' 

*  Each  Catalog  transaction  (CXF/G/K)  must 
accompany  a  valid  LISSR  transaction  with  identical  control  ele¬ 
ments  . 

The  SSR  File  Maintenance  program  module  performs 
package  validation  and  matching  transaction  validations.  The 
package  validation  includes  checking  for  a  valid  PDSSR  for  each 
LISSR  based  on  matching  control  elements.  Also  all  input  LIAC 
transactions  and  LISSR  transactions  having  TCC  ■  C,  D,  R  or  S, 
are  matched  to  the  SSR  Suspense  File  for  a  matching  LISSR  trans¬ 
action  (based  on  control  elements)  with  TCC  *  blank  or  V. 
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The  above  validations  apply  equally  to  incoming 
and  outgoing  SSR  transactions.  The  basic  control  data  elements 
used  by  the  Air  Force  include  the  PCC  and  internally  assigned 
Document  Number  for  outgoing  PDSSR  transactions;  and  PCC  and  DOR 
for  incoming  PDSSR  transactions.  The  ISN  is  added  to  these  for 
outgoing  and  incoming  LISSR,  catalog,  and  LIAC  transactions.  All 
other  data  elements  validated  as  described  in  the  detailed  vali¬ 
dation  criteria  below  are  considered  to  be  key  data  elements  by 
the  Air  Force. 

d .  Defense  Logistics  Agency  (DLA) 

( 1 )  Program  Structure 

DLA,  acting  only  as  a  CIMM,  receives  SSRs  for 
processing  from  Service  SICCs.  The  DLA  system  design  includes 
validation  in  the  SSR  Validation  and  SSR  Daily  File  Maintenance 
program  modules  shown  in  Figure  VI-3,  Volume  II,  Part  1,  Chapter 
VI.  All  input  transactions  are  sorted  into  ACT,  ACF ,  PCC,  DOR, 
ISN,  DIC  and  Card  Number  sequence  prior  to  validation.  The  SSR 
Validation  Program  module  performs  validation  on  all  input  SSR 
transactions  including  PDSSR,  LISSR,  catalog,  and  LIAC  transac¬ 
tions.  Each  transaction  is  validated  until  the  first  error  is 
encountered.  When  an  error  is  encountered,  a  reject  advice 
transaction  is  automatically  generated  with  an  appropriate  reject 
code  from  the  IMM  Manual  for  transmission  to  the  SICC.  The  SSR 
Validation  program  module  does  no  file  recording. 

The  SSR  Daily  File  Maintenance  program  module 
performs  validation  of  offer  reply  transactions  only.  This 
validation  consists  of  matching  these  LIAC  transactions  against 
the  SSR  Suspense  File  on  control  data  elements.  When  a  match  is 
not  found  these  transactions  are  not  posted  to  the  file,  but  are 
printed  out  for  functional  action.  This  program  module  performs 
all  file  recording  in  the  daily  application.  SSR  transactions 
posted  to  the  SSR  Suspense  File  by  this  program  module  include: 

*  Valid  initial  submission  provisioning  and 
nonprovisioning  PDSSR,  LISSR,  and  catalog  transactions. 

*  Valid  LISSR  change  transactions  containing 
TCC  =  'S'  and  the  associated  PDSSR  transactions. 

*  Invalid  initial  submission  provisioning  and 
nonprovisioning  PDSSR,  LISSR  and  catalog  transactions  not  con¬ 
taining  package  or  control  data  element  errors. 

*  Invalid  LISSR  change  transactions  containing 
TCC  *  'S'  and  the  associated  PDSSR  transactions  not  containing 
package  or  control  data  element  errors. 
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Automatically  generated  advice  transactions 


* 

*  Valid  offer  reply  transactions. 

Transactions  not  posted  to  the  SSR  Suspense  File 

include : 


*  Valid  and  invalid  LISSR  change  transactions 
(except  those  with  TCC  =  S  as  explained  above). 

*  PDSSR,  LISSR  and  catalog  transactions  con¬ 
taining  a  package  or  control  data  element  error. 

*  Invalid  offer  reply  transactions. 

*  Valid  and  invalid  followup  transactions. 

*  Followup  response  transactions. 

The  DLA  SSR  Application  provides  for  automatic 
generation  of  all  followup  response  transactions  directly  from  a 
match  of  followup  transactions  against  the  SSR  Suspense  and  SSR 
History  Files.  All  advice  transactions  are  also  automatically 
generated  either  directly  from  validation  or  DLSC  screening 
results  or  indirectly  thru  file  maintenance  transactions.  These 
automatically  generated  transactions  are  not  validated  prior  to 
transmission  via  AUTODIN  to  the  appropriate  SICCs. 

(2)  Validation  Levels 


Four  validation  levels  are  used  in  the  SSR 
Validation  Program  Module.  These  are  package  validation,  dupli¬ 
cate  validation,  control  data  element  validation  and  detail  data 
element  validation  levels.  Although  DLA  identifies  NSN,  PSCN, 
Manufacturers  Reference  Number/FSCM,  Procurement  Method  Code, 
Unit  Price  and  Unit  of  Issue  as  Key  data  elements,  these  are  not 
validated  separately,  but  as  part  of  detail  data  element  valida¬ 
tion.  The  hierarchy  of  validation  levels  is  more  complex  than 
those  of  the  other  Components.  The  PDSSR  Control  Data  Elements 
are  validated  first  followed  by  validation  of  all  PDSSR  detail 
data  elements.  Package  validations  and  duplicate  validations 
are  then  performed  followed  by  validation  of  LISSR  and  catalog 
transaction  control  data  elements.  Detail  data  elements  of  the 
LISSR  and  catalog  transactions  are  validated  last.  Specific 
validation  of  the  control  and  detail  data  elements  is  given  in 
the  Detailed  Validation  Criteria  section  below.  The  control 
data  elements  used  by  DLA  include  ACT,  ACF ,  PCC,  DOR,  DIC  and 
ISN. 


Package  validations  performed  by  this  program 
module  Include  both  PCC  and  LISSR  package  validations.  Each 
valid  PDSSR  transaction  must  be  accompanied  by  one  or  more  valid 
LISSR  transactions  with  matching  ACF,  PCC  and  DOR.  Also  each 
valid  LISSR  transaction  must  be  accompanied  by  a  valid  PDSSR 
transaction  with  matching  ACF,  PCC  and  DOR.  Each  Part  Number 
LISSR  must  consist  of  a  Card  Number  1  transaction  and  Card  Number 
2  transaction  with  matching  control  data  elements.  An  item  name 
transaction  must  accompany  a  valid  Part  Number  or  PSCN  LISSR 
transaction  with  matching  ACF,  PCC,  DOR  and  ISN.  Other  catalog 
transactions  must  be  accompanied  by  a  valid  LISSR  transaction 
with  matching  ACF,  PCC,  DOR  and  ISN. 

Duplicate  validations  performed  by  the  SSR 
validation  program  module  include  checks  for  duplicates  on  both 
a  total  transaction  basis  and  on  a  control  data  element  basis. 
When  total  transaction  duplicates  are  found,  the  first  transac¬ 
tion  in  the  series  is  processed  and  the  remaining  duplicates 
are  dropped  from  further  processing.  When  a  duplication  of 
control  elements  occurs  on  two  or  more  PDSSR  or  LISSR\transac- 
tions,  all  transactions  with  duplicate  control  elements  (but 
different  identification  data)  are  rejected  as  invalid.  Item 
Name  and  Additional  User  transactions  are  not  validated  for 
duplicate  control  data  elements.  Additional  Reference  Number 
transactions  with  matching  control  data  elements  are  valid  and 
are  processed  accordingly. 

The  SSR  Daily  File  Maintenance  Program  Module 
performs  the  offer  reply  transaction  match  validation  described 
above.  In  addition,  when  a  submitted  LISSR  transaction  matches 
to  an  existing  record  on  the  SSR  Suspense  File  on  ACF,  PCC,  DOR 
and  ISN,  it  must  contain  TCC  =  'S'  else  it  is  rejected  as  a 
duplicate. 

e.  GSA  Validation  Criteria 


( 1 )  Program  Structure 

GSA  acts  only  as  a  CIMM  and  as  such  processes 
only  incoming  SSR  transactions.  The  GSA  system  design  provides 
for  validation  of  incoming  SSR  transactions  in  two  program  mod¬ 
ules.  Followup  transactions  are  processed  in  a  separate  program 
module  and  are  not  subjected  to  the  validations  described  here. 
Input  SSR  transactions  are  sorted  into  ACF,  DOR,  PCC,  ISN,  TCC, 
DIC  and  Card  Number  sequence  prior  to  validation. 

The  first  program  module  performing  validation 
(SSR  Validation  program  module)  does  the  majority  of  validation. 
This  program  module  performs  validation  on  all  incoming  PDSSR, 
LISSR,  and  catalog  transactions.  Transactions  are  validated 
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until  the  first  error  is  encountered  and  reject  advice  transac¬ 
tions  are  automatically  generated  containing  an  IMM  Manual  reject 
code  for  transactions  found  in  error.  Transactions  in  error  are 
printed  on  a  reject  listing  for  functional  use.  This  listing 
shows  the  reject  code  applied;  however,  when  certain  data  ele¬ 
ments  are  found  to  be  in  error  a  GSA  internal  reject  code  is 
shown.  This  is  particularly  true  when  an  error  is  found  in  a 
PDSSR  transaction  and  an  ATC  *52'  is  used  in  the  advice  transac¬ 
tion.  These  unique  error  codes  are  listed  in  Appendix  D  along 
with  those  of  the  other  Services.  This  program  module  performs 
no  posting  to  automated  files* 

The  second  program  madule  (SSR  File  Maintenance) 
posts  valid  and  invalid  SSR  transactions  to  the  GSA  SSR  Suspense 
File.  Some  valid  transactions  are  validated  for  a  match/no  match 
condition  agdinst  the  SSR  Suspense  File  by  this  program  module. 

An  example  of  this  matching  validation  would  be  checking  an  SSR 
change  transaction  for  an  initial  submittal. 

Followup  transactions  are  matched  to  the  SSR 
Suspense  File  in  a  separate  program  module.  Followup  response 
transactions  are  automatically  generated  based  on  the  results  of 
this  matching  process.  Automatically  generated  transactions  are 
not  validated  prior  to  submittal  to  the  SICC.  It  is  unknown 
whether  manually  generated  advice  transactions  and  offer  reply 
transactions  are  validated. 

(2)  Validation  Levels.  Validation  is  performed  at 
three  levels  in  the  GSA  system  design.  The  SSR  Validation  pro¬ 
gram  module  performs  package  level  validations,  match/duplicate 
level  validation-  and  detail  data  element  level  validation.  Con¬ 
trol  data  elements  and  key  data  elements  are  not  identified 
separately  for  validation.  As  described  above  the  SSR  file  main¬ 
tenance  program  module  performs  match/duplicate  validation  only. 
Since  this  system  is  in  the  design  stage  and  since  the  actual 
validation  criteria  shown  in  the  system  design  are  generally 
consistent  with  those  performed  by  other  Components,  the  detail 
data  element  validation  criteria  is  not  described. 

f .  DODSSR  Validation  Criteria 

(1)  Program  Structure.  The  DODSSR  validation  design 
uses  two  program  modules  to  perform  the  required  validations. 

All  transactions  in  the  DODSSR  data  base  including  PDSSR  trans¬ 
actions,  LISSR  transactions,  catalog  transactions  and  L1AC 
transactions  are  required  to  be  validated  by  this  design.  The 
transactions  in  the  DODSSR  data  base  were  sorted  into  ACF,  ACT, 
PCC,  DOR,  ISN,  DIC,  and  Card  Number  sequence  prior  to  validation. 
Each  transaction  is  validated  for  up  to  ten  error  conditions 
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before  terminating  the  validation  effort.  A  DODSSR  reject  trans¬ 
action  was  designed  to  accommodate  the  control  data  elements,  an 
ATC  relating  each  error  encountered  and  a  series  of  report  codes 
for  use  in  automated  analysis  of  the  errors  found. 

( 2 )  Validation  Levels 


The  DODSSR  validation  is  performed  at  five 
levels  in  two  program  modules.  The  first  program  module  per¬ 
forms  validation  at  the  control  data  element  level,  duplicate 
validation  level,  detail  data  element  validation  level,  and 
LISSR  package  validation  level.  The  duplicate  validation  level 
contains  no  file  match  criteria  because  there  is  no  SSR  Suspense 
File  within  the  DODSSR  data  base  against  which  such  a  match  could 
take  place.  The  second  program  module  performs  PCC  package  vali¬ 
dation  only.  The  PCC  package  validation  matches  PDSSR  transac¬ 
tions  to  LISSR  transactions  based  on  control  data  elements  (ACF, 
ACT,  PCC,  DOR).  Within  the  DODSSR  data  base,  2.5  percent  of  the 
errors  encountered  consisted  of  PCC  package  errors  for  PDSSR 
transactions  . 


The  first  program  module  validates  the  control 
data  elements  (ACF,  ACT,  PCC,  DOR)  in  PDSSR  transactions  first. 
PDSSR  transactions  are  next  examined  for  duplicates  based  on 
these  control  elements  and  DIC.  When  duplicate  PDSSR  transac¬ 
tions  are  found,  all  matching  transactions  are  flagged  as  dupli¬ 
cates.  Duplicate  PDSSR  transactions  accounted  for  0.6  percent 
of  the  errors  found  in  the  DODSSR  data  base.  Detail  data  ele¬ 
ment  validation  of  PDSSR  transactions  is  then  performed.  LISSR 
transactions,  catalog  transactions  and  LIAC  transactions  are 
validated  for  duplicate  transactions  first  based  on  ACT,  ACF, 
PCC,  DOR,  ISN,  DIC,  and  Card  Number.  As  with  PDSSR  transactions 
all  matching  transactions  are  flagged  as  duplicates.  These 
duplicates  made  up  30.8  percent  of  the  errors  encountered  in  the 
DODSSR  data  base.  After  duplicate  validation,  control  data  ele¬ 
ments  are  validated  followed  by  detail  data  element  validation. 
Several  LISSR  package  validations  are  done  in  the  first  program 
module  . 


Each  valid  item  name  transaction  is  matched  to 
a  Part  Number  or  PSCN  LISSR  transaction  with  the  same  ACF,  ACT, 
PCC,  DOR  and  ISN.  Similarly,  each  valid  Additional  Reference 
Number  and  valid  Additional  User  transaction  is  matched  on  ACF, 
ACT,  PCC,  DOR,  and  ISN  to  a  LISSR  transaction.  When  a  match 
occurs,  bui  the  corresponding  LISSR  is  invalid,  the  catalog 
transaction  also  becomes  invalid.  Each  part  number  LISSR  must 
consist  of  a  card  number  1  transaction  and  card  number  2  trans¬ 
action  with  matching  ACF,  ACT,  PCC,  DOR,  ISN,  DIC,  and  TCC. 

The  final  LISSR  package  check  is  to  match  each  LISSR  submitted 
with  TCC  equal  to  *R'  to  a  corresponding  LISSR  with  TCC  equal  to 
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'S'  and  corresponding  ACF,  ACT,  DOR,  PCC  and  ISN.  PCC  and  LISSR 
package  errors  for  LISSR  transactions  were  the  most  frequent 
errors  found  in  the  DODSSR  data  base  and  constituted  39.7  per¬ 
cent  of  the  errors  encountered. 

The  frequency  of  duplicate  errors  encountered 
in  the  DODSSR  data  base  is  artifically  high  due  to  a  single  fac¬ 
tor.  Generally,  duplicate  validation  occurs  on  a  cycle  basis 
whenever  the  Component  SSR  Application  is  executed  (daily,  bi¬ 
weekly,  etc.).  With  the  DODSSR  data  base,  all  transactions 
collected  over  an  eight  month  time  period  were  validated  in  a 
single  cycle.  This  condition  caused  duplicates  to  occur  simply 
because  of  the  length  of  the  cycle  not  necessarily  because  the 
transactions  are  actually  duplicative  of  one  another.  For 
example,  in  the  DODSSR  data  base  validation,  PDSSR  change  trans¬ 
actions  would  be  duplicative  of  initial  submission  PDSSR  trans¬ 
actions  because  both  contain  identical  control  elements;  also 
initial  advice  transactions  and  final  advice  transactions  would 
appear  to  be  duplicative  for  the  same  reason.  This  lengthy 
cycle  affects  multiple  followup  and  followup  response  transac¬ 
tions  for  the  same  ISN  as  well.  Another  lesser  cause  for  the 
seeming  high  volume  of  duplicates  is  an  error  in  the  DODSSR 
validation  criteria  which  allows  for  only  a  single  Additional 
Reference  Number  Transaction  for  each  item.  The  IMM  Manual 
allows  for  multiple  Additional  Reference  Number  Transactions  to  be 
submitted  with  a  single  LISSR  transaction. 

The  DODSSR  validation  criteria  does  not  include 
a  check  for  total  duplicates.  The  DODSSR  Study  Team  believes 
that  a  total  duplicate  check  is  a  necessary  part  of  any  complete 
SSR  validation  package;  however,  this  validation  was  performed 
as  a  byproduct  of  establishing  the  DODSSR  data  base  as  discussed 
in  Chapter  I  of  this  Volume.  Therefore,  it  was  omitted  from  the 
DODSSR  validation  criteria  to  prevent  this  validation  from  being 
re  pea  ted  . 

3 .  Detailed  Validation  Criteria 

In  this  paragraph,  the  detailed  data  element  validation 
criteria  of  each  of  the  Components  along  with  that  used  for 
validation  of  the  DODSSR  data  base  is  presented.  The  criteria 
presented  is  generally  expressed  in  terms  of  alphabetic,  numeric 
or  alphanumeric  entries.  The  accepted  definition  of  alphanumeric 
in  data  processing  circles  include  alphabetic  characters,  numbers, 
space,  and  some  special  characters;  however,  the  general  usage 
of  alphanumeric  in  this  section  includes  only  alphabetic  charac¬ 
ters  and  numbers.  Of  the  specific  criteria  presented  here,  only 
that  of  the  Air  Force  and  DLA  were  fully  implemented  during  the 
DODSSR  data  collection.  The  other  Components  were  using  the  man¬ 
ual  validations  described  in  an  earlier  section  during  the  data 
collection  time  frame.  Due  to  this  variability  in  implementa¬ 
tion  status,  the  comparisons  of  validation  criteria  presented 
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in  this  Chapter  are  a  reflection  of  what  could  happen  when  all 
Coaponents  reach  full  Implementation  status  rather  than  what 
necessarily  occurred  during  the  DODSSR  data  collection  as  dis¬ 
cussed  in  Chapter  I  of  this  Volume. 

The  discussion  here  is  centered  around  the  four  basic 
types  of  SSR  transactions  currently  in  being.  These  types  are 
PDSSR  transactions,  LISSR  transactions,  catalog  transactions  and 
LIAC  transactions.  Each  type  will  be  discussed  separately  with 
specific  data  elements  arranged  in  alphabetic  sequence. 

a .  PDSSR  Transactions 

(1)  Activity  Code  From.  This  data  element  is  con¬ 
sistently  validated  by  IMMs  against  an  activity  code  table  to 
insure  submission  of  a  valid  activity  code.  The  validation  per¬ 
formed  by  SICC  Services  varies  from  the  simple  valid  activity 
code  determination  by  the  Army  to  the  automated  insertion  of  the 
processing  activity  code  by  the  Navy.  The  DODSSR  validation 
criteria  for  this  data  element  matches  the  entry  to  an  activity 
code  table. 


(2)  Activity  Code  To.  Validation  of  this  data  ele¬ 
ment  differs  from  Component  to  Component.  As  SICCs  the  Army  and 
Air  Force  validate  this  data  element  for  a  valid  activity  code 
only.  The  Navy  also  validates  this  data  element  for  a  valid 
activity  code,  but  ties  this  validation  to  the  DIC;  i.e.,  when 
the  DIC  is  CWA ,  the  Activity  Code  must  reflect  a  CIMM  activity. 

As  an  IMM  the  Army  performs  validation  for  a  valid  activity  code 
only.  Other  IMMS  check  to  make  sure  the  Activity  Code  To  reflects 
the  Activity  Code  of  the  processing  activity;  i.e.  if  the  pro¬ 
cessing  activity  is  DESC,  the  Activity  Code  To  must  be  TX.  The 
DODSSR  validation  criteria  for  this  data  element  is  identical  to 
that  for  Activity  Code  From  described  above. 

(3)  Contract  Control  Number.  This  data  element  is 
generally  validated  to  ensure  an  entry  is  made  (data  element 
field  not  blank);  however,  as  WIMMs  the  Navy  and  Air  Force  bypass 
validation  of  this  data  element.  The  DODSSR  validation  criteria 
validates  this  data  element  for  a  nonblank  first  character. 

(4)  Date  NSNs  are  Required.  As  SICCs  the  Services 
validate  this  data  element  for  all  spaces  or  a  numeric  entry; 
when  found  to  be  invalid,  the  data  element  is  edited  to  reflect 
all  spaces  by  the  Navy  and  Air  Force.  The  Army  as  an  IMM  vali¬ 
dates  this  data  element  for  all  spaces  or  a  numeric  entry.  DLA 
validates  this  data  element  for  a  numeric  entry  and  inserts  the 
current  date  plus  60  days  when  found  to  be  invalid.  The  Navy 
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and  Air  Force  bypass  validation  of  this  data  element  as  WIMMs. 
The  DODSSR  validation  criteria  for  this  data  element  consists  of 
a  check  for  spaces  or  a  numeric  entry  which  is  greater  than  the 
Date  of  Request i  but  less  than  the  Date  Repair  Parts  Required* 

(5)  Date  Repair  Parts  Are  Required.  The  Army  and 
Navy  as  SICCs  validate  this  data  element  for  a  numeric  entry. 

The  Navy  inserts  the  current  date  plus  270  days  when  an  error 
condition  is  encountered.  The  Air  Force  as  a  SICC  validates 
this  data  element  for  all  spaces  or  a  numeric  entry  and  edits 
the  data  element  to  all  spaces  when  an  error  is  found.  The  Army 
and  DLA  as  IMMs  validate  this  data  element  for  a  numeric  entry. 
The  Navy  and  Air  Force  as  WIMMs  bypass  validation  of  this  data 
element.  The  DODSSR  validation  criteria  for  this  data  element 
consists  of  a  check  for  a  valid  date;  i.e,  first  character  equal 
to  0-9,  second  thru  fourth  characters  equal  to  001-366. 

(6)  Date  of  Request.  The  Army  as  a  SICC  and  IMM, 
the  Navy  as  WIMM,  and  DLA  all  validate  this  data  element  for  a 
numeric  entry.  The  Navy  as  a  SICC  automatically  generates  this 
data  element  as  the  current  date  plus  14  days  for  initial  sub¬ 
mission  PDSSR  transactions  and  validates  this  data  element  for  a 
numeric  entry  for  PDSSR  change  transactions.  The  Air  Force 
automatically  assigns  a  Date  of  Request  as  a  SICC  and  as  a  WIMM 
validates  DOR  for  an  alphanumeric  entry  not  equal  to  spaces. 

The  DODSSR  validation  criteria  for  this  data  element  consists  of 
a  check  for  a  valid  date;  l.e.  first  character  equal  to  0-9, 
second  thru  fourth  characters  equal  to  001-366. 

(7)  Document  Identifier  Code.  Each  Component  vali¬ 
dates  this  data  element  for  a  valid  code  from  the  IMM  Manual. 
This  validation  may  occur  within  the  SSR  Application  of  the  Com¬ 
ponent  or  as  a  means  of  routing  transactions  received  from  many 
sources  to  the  Component  SSR  Application.  The  DODSSR  validation 
criteria  provides  for  bypassing  validation  of  this  data  element. 
The  reasoning  behind  this  decision  was  that  each  transaction  was 
validated  for  an  IMM  Manual  DIC  prior  to  being  placed  in  the 
DODSSR  data  base  as  explained  in  Chapter  I  of  this  Volume. 

(8)  End  Item  Delivery  Code.  Component  validation 
of  this  data  element  differs  extensively.  The  Army  as  SICC  and 
IMM  validates  this  data  element  for  all  0's  or  all  X's  only  when 
the  type  Change  Code  equals  *N';  otherwise  the  data  element  is 
bypassed.  The  Navy  as  SICC  and  WIMM  validates  this  data  element 
for  all  0's,  all  X's  or  numeric  with  first  character  equal  to  0- 
9;  second  character  equal  to  l,  2,  3,  or  4;  third  and  fourth 
characters  equal  to  00-99.  When  an  invalid  condition  is  found 
the  Navy  edits  this  data  element  to  all  0's.  The  Air  Force  as 
SICC  validates  this  data  element  for  a  numeric  entry  and  edits 
the  field  to  all  0's  when  invalid.  As  a  WIMM  the  Air  Force 
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bypasses  validation  of  this  data  element*  DLA  validates  this 
data  element  for  all  0's  or  a  numeric  entry  with  the  second 
character  equal  to  1,  2,  3,  or  4.  The  DODSSR  validation  criteria 
is  a  check  for  a  numeric  quantity  with  the  second  character  equal 
to  0,  1,  2,  3,  or  4. 

(9)  End  Item  Name,  NSN,  Type,  Model  Number.  This 
data  element  is  validated  to  ensure  an  entry  is  made  and  that 
the  entry  is  left  justified  by  all  SICCs,  CIMMs  and  by  the  Army 
as  a  WIMM.  The  Navy  and  Air  Force  as  WIMMs  bypass  validation  of 
this  data  element.  The  DODSSR  validation  criteria  checks  for  a 
left  justified  entry. 

(10)  End  Item  Quantity.  This  data  element  is  vali¬ 
dated  for  a  numeric  entry  by  all  SICCs  and  IMMs  except  Air  Force 
who  as  a  WIMM  bypasses  validation  of  this  data  element.  3LA 
performs  an  additional  validation  on  this  data  element  in  that 
the  numeric  value  must  be  greater  than  zero  unless  the  PDSSR 
reflects  TCC  equal  to  V  (nonprovisioning).  The  DODSSR  valida¬ 
tion  criteria  calls  for  a  numeric  entry  in  this  data  element. 

(11)  FSCM  Prime.  The  Services  as  SICCs  and  IMMs 
validate  this  data  element  for  an  alphanumeric  entry  with  no 
spaces.  Air  Force  as  a  WIMM  bypasses  validation  of  thiB  data 
element.  DLA  validates  this  data  element  for  a  numeric  quantity. 
Due  to  the  alternate  usage  of  this  field  in  the  DODSSR  data  col¬ 
lection  as  described  in  Chapter  I  of  this  Volume,  the  DODSSR 
Validation  Criteria  allowed  for  bypassing  validation  of  this 
data  element . 
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Number  of  SSRs  Enclosed.  This  data  element  is 
ed  for  a  numeric  quantity.  The  Navy  as  SICC 
this  data  element,  but  mechanically  assigns  a 
a  element  based  on  the  number  of  valid  LISSR 
to  the  SICC  SSR  Suspense  File.  The  Navy  and 
s  bypass  validation  of  this  data  element;  DLA 
lement  to  a  value  of  1  when  found  to  be  inva- 
Validation  Criteria  calls  for  checking  for  a 
editing  this  data  element  when  an  invalid 
red . 


(13)  Percent  End  Items  East.  This  data  element  is 
generally  validated  for  a  numeric  entry.  The  Army  SICC  and  IMM 
validation  criteria  include  a  check  for  a  mandatory  zero  entry 
when  the  TCC  equals  'N'  (initial  submittal).  The  Navy  as  SICC 
and  WIMM  allows  an  entry  of  'XX'  as  valid  and  will  edit  outgoing 
PDSSRs  to  a  value  of  '50'  when  an  Invalid  condition  exists.  The 
Air  Force  as  WIMM  bypasses  validation  of  this  data  element.  The 
DODSSR  Validation  Criteria  provides  for  checking  the  field  for  a 
numeric  entry. 
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(14)  Provisioning  Control  Code.  This  data  element 
Is  consistently  validated  by  all  Components  and  as  part  of  the 
DODSSR  Validation  Criteria  for  an  alphanumeric  entry  with  no 
spaces  or  special  characters  allowed. 

(15)  Type  Change  Code.  This  data  element  Is  gener¬ 
ally  validated  for  a  valid  entry  (N/P/V).  The  Navy  and  Air  Force 
as  SICCs  will  edit  this  field  to  'N*  when  an  invalid  condition 
exists.  DLA  includes  space  as  a  valid  entry,  but  edits  the  space 
to  an  'N*  when  found.  The  Air  Force  as  W1MM  bypasses  validation 
of  this  data  element.  The  DODSSR  Validation  Criteria  for  this 
data  element  parallels  that  of  DLA. 

(16)  Weapons  System  Code.  This  data  element  is  vali¬ 
dated  for  a  numeric  entry  or  spaces  by  Army  as  SICC  and  IMM,  and 
by  Air  Force  as  SICC.  Air  Force  as  WIMM  bypasses  validation  of 
this  data  element  as  does  Navy  as  SICC  and  WIMM.  DLA  validates 
this  data  element  for  a  numeric  quantity  and  edits  the  field  to 
spaces  when  invalid.  The  DODSSR  validation  criteria  for  this 
data  element  parallels  that  of  DLA. 

b .  LISSR  Transactions 

(1)  Activity  Code  From.  Validation  of  this  data 
element  is  identical  to  that  described  in  subsection  I II . C . 3 . a  .  ( 1 ) 
above . 

(2)  Activity  Code  To.  Validation  of  this  data  ele¬ 
ment  1 s  identical  to  that  described  in  subsection  III. C. 3. (2) 
above . 

(3)  Acquisition  Advice  Code  (AAC).  Validation  cri¬ 
teria  for  this  data  element  varies  widely  from  Component  to 
Component.  The  Army  as  SICC  and  IMM  validates  the  AAC  for  a 
space  or  an  alphabetic  entry  (except  U).  The  Navy  as  SICC  vali¬ 
dates  this  field  for  an  alphabetic  entry,  but  edits  the  field  to 
space  when  invalid  or  to  a  value  of  ’J*  when  the  Retail  and 
Replenishment  Quantities  are  both  zero.  The  Air  Force  as  SICC 
edits  this  field  to  space  or  if  the  Retail  and  Replenishment 
Quantities  are  both  zero  to  'J'  without  validation.  Both  the 
Navy  and  Air  Force  as  WIMMs  bypass  validation  of  this  data  ele¬ 
ment.  DLA  validates  this  data  element  for  a  value  of  space,  D, 

Z,  or  J.  The  DODSSR  validation  criteria  allows  for  validation 
of  this  data  element  for  a  value  of  'J'  when  both  the  retail  and 
replenishment  quantities  are  zero;  otherwise  the  data  element  is 
bypassed. 

(4)  Card  Number.  This  data  element  is  consistently 

validated  by  all  Components  and  by  the  DODSSR  validation  cri¬ 
teria  for  a  value  of  or  '2.' 
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(5)  Date  of  Request  (DOR).  Validation  of  this  data 
element  is  identical  to  that  described  for  PDSSR  transactions  in 
subsection  I I I . C . 3 . a . ( 6 )  above. 

(6)  Date  Technical  Data  to  be  Supplied  (DTDS).  This 
data  element  is  applicable  on  SICC  to  C1MM  part  number  L1SSR 
transactions  only;  therefore,  no  WIMM  validation  is  required. 

The  Army  as  a  SICC  and  C IMM  bypass  validation  of  this  data  ele¬ 
ment.  The  Navy  as  a  SICC  validates  this  data  element  for  a 
numeric  value  and  edits  the  field  to  spaces  when  invalid.  The 
Air  Force  validates  this  data  element  for  spaces  or  a  numeric 
value.  DLA  validates  DTDS  for  a  numeric  value  and  edits  the 
field  to  all  0's  when  invalid.  The  DODSSR  validation  criteria 
provides  for  validating  this  data  element  for  a  valid  date  or 
spaces  . 


(7)  Demilitarization  (Demil)  Code.  This  data  ele¬ 
ment  is  applicable  to  inactive  NSN,  PSCN  and  Part  Number  SICC  to 
CIMM  LISSR  transactions  only.  All  Components  and  the  DODSSR 
validation  criteria  provide  for  validating  this  data  element  for 
a  valid  code  (A-M,  except  I)  with  one  exception.  Army  valida¬ 
tion  calls  for  this  data  element  to  be  a  space  on  inactive  NSN 
LISSR  transactions.  Also  Navy  as  a  SICC  edits  this  data  element 
by  inserting  a  value  of  'A*  when  found  to  be  in  error. 

(8)  Document  Availability  Code  (DAC).  This  data 
element  is  applicable  to  Part  Number  SICC  to  CIMM  LISSR  transac¬ 
tions  only.  Validation  criteria  for  this  data  element  varies 
from  Component  to  Component.  The  Army  as  SICC  and  CIMM  vali¬ 
dates  this  data  element  for  a  value  equal  to  1-9,  A-H .  The  Navy 
as  SICC  validates  this  data  element  for  a  value  equal  to  1-6,  9, 
A-H.  The  Air  Force  as  SICC  does  no  validation  of  the  DAC,  but 
simply  edits  this  field  to  a  value  of  '5.'  DLA  validates  this 
data  element  for  a  value  equal  to  space,  1-6,  9,  A-H  and  edits 
the  field  to  space  when  an  error  is  found.  The  DODSSR  valida¬ 
tion  criteria  parallels  that  of  DLA. 

(9)  Document  Identifier  Code  (PIC).  Validation  of 
this  data  element  is  identical  to  that  described  for  PDSSR  trans¬ 
action  in  subsection  1 1 1 . C . 3 . a  .  ( 7  )  above. 

(10)  FSCM.  All  Components  except  DLA  validate  this 
data  element  for  an  alphanumeric  entry  with  no  spaces.  DLA 
validates  this  data  element  for  a  numeric  entry.  The  DODSSR 
validation  criteria  bypassed  validation  of  this  data  element  due 
to  an  alternate  usage  of  this  field  related  to  the  DODSSR  data 
collection  and  described  in  Chapter  I  of  this  Volume. 

(11)  Interchangeability  Code.  Validation  of  this 
data  element  varies  from  Component  to  Component.  The  Army,  as 
SICC  and  IMM,  validates  this  data  element  for  a  valid  code  entry 
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(NI,  OM,  OW,  TM,  TW)  when  the  LISSR  transaction  TCC  equals  ' R ' 
or  'S.'  The  Navy  as  SICC  validates  this  data  element  for  a 
valid  code  entry  and  edits  the  field  to  spaces  when  an  invalid 
entry  is  foi,_d.  The  Air  Force  as  SICC  validates  this  data  ele¬ 
ment  for  a  valid  code  entry  when  the  LISSR  TCC  equals  'R'  or  'S' 
and  edits  the  field  to  spaces  when  errors  are  found.  The  Navy 
and  Air  Force  as  WIMMs  bypass  validation  of  this  data  eleaent. 

DLA  provides  for  editing  this  field  to  spaces  when  an  invalid 
code  is  submitted.  The  DODSSR  validation  criteria  calls  for 
validating  this  data  element  for  a  valid  code  entry  when  the 
LISSR  TCC  equals  'R*  or  'S'  and  for  spaces  when  the  LISSR  TCC  is 
not  ’ R*  or  • S . ' 

( 12 )  Item  Identification  (II)  Data  Collaborator. 

This  data  element  is  applicable  to  SICC  to  WIMM  LISSR  transac¬ 
tions  only.  The  Army  bypasses  validation  of  this  data  element. 
The  Navy  as  a  SICC  validates  this  data  element  for  an  alphanu¬ 
meric  entry  with  no  spaces.  The  Air  Force  as  a  SICC  performs  no 
validation  of  this  data  element  but  automatically  edits  the  field 
to  spaces.  This  data  element  bypasses  validation  on  a  WIMM  basis 
by  all  Services.  The  DODSSR  validation  criteria  bypasses  vali¬ 
dation  of  this  data  element. 

(13)  Item  Identification  (II)  Data  Receiver.  This 
data  element  is  applicable  to  SICC  to  WIMM  LISSR  transactions 
only.  Validation  of  this  data  element  is  identical  to  that 
described  for  II  Data  Collaborator  above. 

(14)  Item  Management  Code  (IMC).  This  data  element 
is  applicable  to  SICC  to  CIMM  LISSR  transactions  only.  Valida¬ 
tion  criteria  for  this  data  element  varies  from  Component  to 
Component.  The  Army  as  SICC  and  CIMM  validates  this  data  ele¬ 
ment  for  an  alphanumeric  entry  (space  or  special  characters 
excluded).  The  Navy  validates  this  data  element  for  an  entry  of 
D,  E,  F,  H,  J,  K,  L,  M,  N,  0,  Q,  R,  S,  T,  U,  V,  W,  or  Z.  The 
Air  Force  automatically  edits  this  data  element  based  on  ACT 
(ACT  *  AZ,  IMC  -  F;  ACT  -  another  CIMM  activity,  IMC  -  Z).  DLA 
validates  this  data  element  for  an  entry  of  Z  and  edits  this 
field  to  Z  when  found  invalid.  The  DODSSR  validation  criteria 
provides  for  validating  this  data  element  for  an  entry  of  'F'  or 
'  Z.  ' 


(15)  Item  Serial  Number  (ISN).  Validation  of  this 
data  element  varies  from  Component  to  Component.  The  Army  vali¬ 
dates  the  ISN  for  no  spaces  in  characters  1  thru  4.  The  Navy 
validates  the  ISN  for  not  all  spaces.  The  Air  Force  validates 
this  data  element  for  no  space  in  character  1,  no  imbedded  spaces 
and  no  special  characters.  DLA  validates  ISN  for  an  alphanumeric 
entry  (0-9,  A-Z)  and  position  1  not  equal  to  space.  The  DODSSR 
validation  criteria  parallels  that  of  DLA. 
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(16)  Manufacturers  Reference  Number.  This  data  ele¬ 
ment  was  consistently  validated  for  an  entry  equal  to  not  all 
spaces  and  left- justified  by  all  Components  except  the  Navy  and 
by  the  DODSSR  validation  criteria.  The  Navy  as  a  SICC  does  not 
require  the  entry  to  be  le f t- jus t i f led  and  as  a  WIMM  bypasses 
validation  of  this  data  element. 

(17)  Materiel  Management  Aggregation  Code  (MMAC). 

This  data  element  is  used  only  by  the  Air  Force  on  SICC  to  WIMM 
LISSR  transactions.  It  is  validated  only  by  the  Air  Force  as  a 
SICC  for  an  alphabetic  entry.  This  data  element  is  bypassed  by 
all  other  Components  and  the  DODSSR  Validation  Criteria. 

(18)  Major  Organizational  Entity  (MOE)  Rule.  This 
data  element  is  applicable  to  SICC  to  WIMM  LISSR  transactions 
only.  The  Army  bypasses  validation  of  this  data  element  except 
on  Part  Number  LISSR  transactions  where  it  is  validated  for  no 
spaces.  The  Navy  as  a  SICC  validates  this  data  element  for  an 
'N'  in  character  1  and  characters  2  thru  4  alphanumeric.  As  a 
WIMM  the  Navy  bypasses  validation  of  this  data  element.  The  Air 
Force  validates  this  data  element  for  an  alphanumeric  entry  with 
no  spaces.  The  DODSSR  validation  criteria  bypasses  validation 
of  this  data  elemenc. 

(19)  NSN .  This  data  element  is  consistently  vali¬ 
dated  by  all  Components  and  the  DODSSR  validation  criteria  to 
check  for  a  numeric  entry. 

(20)  PSCN .  This  data  element  is  generally  validated 

for  an  alphanumeric  (0-9,  A-Z)  entry.  The  Navy  as  a  SICC  vali¬ 
dates  this  data  element  for  characters  1  thru  6  numeric;  charac¬ 
ter  7  equals  to  'P,'  'M,'  or  'U';  characters  8  thru  10  alpha¬ 

numeric  and  characters  11  thru  13  numeric.  DLA  validates  this 
data  element  for  characters  1  thru  6  numeric;  characters  7  thru 

9  equal  to  'PAA';  and  characters  10  thru  13  numeric.  The  DODSSR 
validation  criteria  provides  for  validating  this  data  element 
for  an  alphanumeric  (0-9,  A-Z)  entry. 

(21)  Procurement  Method  Code  (PMC).  This  data  ele¬ 
ment  is  applicable  to  inactive  NSN,  PSCN,  and  Part  Number  LISSR 
transactions.  Validation  of  this  data  element  varies  from  Com¬ 
ponent  to  Component.  The  Army  validates  this  data  element  for 
an  entry  of  space  for  inactive  NSN  LISSR  transactions;  other 
LISSR  transactions  are  validated  for  an  entry  not  equal  to  space. 
The  Navy  as  SICC  validates  this  data  element  for  a  valid  code 
(0-5,  A-Z  except  I,  0,  X)  entry  and  edits  the  field  to  zero  when 
an  error  is  found.  The  Air  Force  as  SICC  validates  this  data 
element  for  an  entry  of  1,  3,  4,  or  5  and  edits  the  field  to  a 
value  of  2  when  an  invalid  condition  is  found.  The  Navy  and  Air 
Force  as  WIMMS  bypass  validation  of  this  data  element.  DLA 
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validates  this  data  element  for  a  value  of  0  thru  5.  The  DODSSR 
validation  criteria  ties  validation  of  this  data  element  to  vali¬ 
dation  of  Unit  Price.  The  criteria  provides  for  PMC  equal  to 
space  when  Unit  Price  equals  spaces  and  PMC  equal  to  0  thru  5 
when  Unit  Price  is  numeric. 

(22)  Production  Leadtime  (PLT).  This  data  element 
is  applicable  to  inactive  NSN,  PSCN  and  Part  Number  LISSR  trans¬ 
actions*  Validation  criteria  for  this  data  element  varies  from 
Component  to  Component.  The  Army  validates  this  data  element  for 
a  numeric  entry  or  spaces  for  inactive  NSN  and  PSCN  LISSR  trans¬ 
actions.  For  Part  Number  LISSR  transactions  the  validation 
criteria  in  the  Army  is  a  numeric  entry  greater  than  zero.  The 
Navy  as  a  SICC  validates  this  data  element  for  a  numeric  entry 
and  if  zero  will  edit  the  field  to  reflect  '01.'  The  Air  Force 
as  a  SICC  validates  this  data  element  for  a  numeric  entry  and 
edits  the  field  to  reflect  a  *06'  when  an  invalid  condition  is 
encountered.  Both  the  Navy  and  Air  Force  as  WIMMs  bypass  vali¬ 
dation  of  this  data  element.  DLA  performs  a  numeric  entry  vali¬ 
dation  on  this  data  element  and  edits  the  field  to  '01'  when 
equal  to  zero  or  to  '15'  when  the  field  is  greater  than  15.  The 
DODSSR  validation  criteria  provides  for  a  numeric  entry  valida¬ 
tion  of  PLT. 

(23)  Provisioning  Control  Code.  Validation  of  this 
data  element  is  identical  to  that  described  for  PDSSR  transac¬ 
tions  in  subsection  1 1 1 .  C  .  3  .  a  .  (  1 A  )  above. 

(24)  Quantity  Per  End  Item.  This  data  element  is 
generally  validated  for  a  numeric  entry  by  all  Components  and 
the  DODSSR  validation  criteria.  The  Navy  as  SICC  will  edit  this 
data  to  '0001'  when  invalid.  The  Air  Force  as  a  WIMM  bypasses 
validation  of  this  data  element.  DLA  validation  criteria  states 
the  data  element  value  must  be  numeric  and  greater  than  zero. 

(25)  Reference  Number  Format  Code  (RNFC).  This  data 
element  is  applicable  to  Part  Number  SICC  to  CIMM  LISSR  transac¬ 
tions  only.  The  Army  bypasses  validation  of  this  data  element. 
The  Navy  validates  this  data  element  for  a  value  of  1  thru  4  and 
edits  the  field  to  4  when  invalid.  The  Air  Force  does  not  vali¬ 
date  this  data  element  but  simply  inserts  a  '1'  in  each  Part 
Number  LISSR  transaction  to  be  submitted  to  a  CIMM  activity. 

DLA  validates  this  data  element  for  a  value  of  space,  1,  2,  or  3 
and  edits  the  field  to  space  when  Invalid.  The  DODSSR  valida¬ 
tion  criteria  checks  RNFC  for  an  entry  of  space,  1,  2,  3,  or  4. 

(26)  Reference  Number  Justification  Code  (RNJC). 

This  data  element  is  applicable  to  Part  Number  SICC  to  CIMM  LISSR 
transactions  only.  The  Army  bypasses  validation  of  this  data 
element.  The  Navy  validates  this  data  element  for  a  value  of 
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space,  1  thru  7  and  edits  the  field  to  space  when  invalid.  The 
Air  Force  does  not  validate  RNJC,  but  edits  the  field  to  space 
on  each  applicable  transaction.  DLA  validates  the  RNJC  for  an 
entry  of  space  or  1  thru  7.  The  DODSSR  validation  criteria 
parallels  that  of  DLA. 

(27)  Reference  Number  Variation  Code  (RNVC).  This 
data  element  is  applicable  to  Part  Number  SICC  to  CIMM  LISSR 
transactions  only.  The  Army  bypasses  validation  of  this  data 
element.  The  Navy  validates  this  data  element  for  an  entry  of 
1,  2,  3,  or  9.  The  Air  Force  does  not  validate  this  data  ele¬ 
ment,  but  inserts  a  value  of  *  2  *  in  each  applicable  transaction. 
DLA  validates  this  data  element  for  an  entry  of  space,  1,  2,  3, 
or  9  and  edits  the  field  to  space  when  invalid.  The  DODSSR 
validation  criteria  for  this  data  element  provides  for  checking 
this  field  for  a  value  of  space  1,  2,  3,  or  9. 

(28)  Replenishment  Quantity.  This  data  element  is 
consistently  validated  by  all  Components  and  the  DODSSR  valida¬ 
tion  criteria  for  a  numeric  entry.  The  Air  Force  as  a  WIMM  by¬ 
passes  validation  of  this  data  element. 

(29)  Retail  Quantity.  This  data  element  is  con¬ 
sistently  validated  by  all  Components  and  DODSSR  Validation 
Criteria  for  a  numeric  entry.  The  Air  Force  as  WIMM  bypasses 
validation  of  this  data  element. 

(30)  Shelf  Life  Code.  This  data  element  is  appli¬ 
cable  to  inactive  NSN  and  PSCN  SICC  to  CIMM  LISSR  transactions 
and  to  all  Part  Number  LISSR  transactions.  Validation  criteria 
varies  from  Component  to  Component.  The  Army  validates  this 
data  element  for  an  entry  of  space  or  a  valid  code  (0-9,  A-H, 

J-N,  P,  Q,  R,  S,  X,  Y,  or  Z).  The  Navy  and  Air  Force  as  SICCs 
validate  this  data  element  for  an  alphanumeric  entry  and  edit 
this  field  to  zero  when  invalid.  As  WIMMs,  the  Navy  and  Air 
Force  bypass  validation  of  this  data  element.  DLA  validates 
this  data  element  for  an  entry  of  A-H,  J-N,  P-S ,  or  X.  The 
DODSSR  validation  criteria  for  Shelf  Life  Code  parallels  that  of 
DLA. 

(31)  Source  Code.  This  data  element  is  applicable 
to  Inactive  NSN  and  PSCN  SICC  to  CIMM  LISSR  transactions  and  to 
all  Part  Number  LISSR  transactions.  Validation  criteria  varies 
from  Component  to  Component.  The  Army  validates  this  data  ele¬ 
ment  for  an  alphanumeric  entry  with  no  spaces.  The  Navy  as  SICC 
validates  this  data  element  for  a  valid  code  (PA,  PB,  PC,  PD,  PE, 
PF,  PC)  and  edits  this  field  to  reflect  PA  when  invalid.  The 
Air  Force  as  SICC  validates  this  data  element  for  an  alphanumeric 
entry  and  edits  this  field  to  reflect  PA  when  invalid.  The  Navy 
and  Air  Force  as  WIMM  bypass  validation  of  this  data  element. 

DLA  validates  Source  Code  for  entry  of  a  valid  code.  The  DODSSR 
validation  criteria  for  Source  Code  parallels  that  of  DLA. 
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(32)  Special  Material  Content  Code  (SMCC).  Valida¬ 
tion  criteria  varies  slightly  from  Component  to  Component  for 
this  data  element.  The  Army  validates  this  data  element  for  an 
alphabetic  entry  (except  I).  The  Navy  and  Air  Force  as  SICCs 
validate  SMCC  for  an  alphabetic  entry  and  as  WIMMs  bypass  vali¬ 
dation  of  this  data  element.  DLA  validates  this  data  element  for 
an  alphabetic  entry  (except  H).  In  all  cases  where  this  data 
element  is  validated  by  a  Component,  it  is  edited  to  reflect 
alpha  'O'  when  invalid.  The  DODSSR  validation  criteria  for  SMCC 
checks  for  an  alphabetic  entry  (except  I,  M,  P) . 

(33)  Technical  Data  Justification  Code  (TDJC).  This 
data  element  is  applicable  to  Part  Number  SICC  to  CIMM  LISSR 
transactions  only.  The  Army  bypasses  validation  of  this  data 
element*  The  Navy  validates  this  data  element  for  an  entry  of  A 
thru  F  or  X  and  edits  the  field  to  reflect  space  when  invalid. 

The  Navy  automatically  edits  this  field  to  reflect  ’X'  when  the 
DAC  equals  *5.’  The  Air  Force  validates  this  data  element  for  a 
value  of  A  thru  F,  X  or  space.  DLA  validates  this  data  element 
for  a  value  of  A  thru  F,  X  or  space  and  edits  this  field  to  re¬ 
flect  space  when  invalid.  The  DoDSSR  validation  criteria  reflects 
that  of  the  Air  Force  . 

(34)  Type  Change  Code  (TCC) .  This  data  element  is 
generally  validated  by  the  Components  for  a  valid  code  (space, 

C,  D,  R,  S,  T,  V).  The  Air  Force  as  WIMM  bypasses  validation  of 
this  data  element.  The  Navy  ties  validation  of  this  data  ele¬ 
ment  in  LISSR  transactions  to  the  value  of  the  TCC  in  the  related 
PDSSR  transaction.  When  the  TCC  in  the  PDSSR  transaction  is 

'N,'  the  TCC  in  the  LISSR  transaction  must  be  space.  When  the 
PDSSR  transaction  TCC  is  'V,'  the  TCC  in  the  LISSR  transaction 
must  be  'V.'  When  the  TCC  in  the  PDSSR  transaction  is  'P,'  the 
TCC  in  the  LISSR  transaction  must  be  C,  D,  R,  S,  or  T.  The  Navy 
as  SICC  will  edit  all  LISSR  transaction  TCCs  to  space  and  the 
associated  PDSSR  transaction  TCC  to  'N'  wh  an  error  condition 
is  found.  The  DODSSR  validation  criteria  tor  TCC  parallels  that 
of  the  Navy  except  for  the  editing  that  the  Navy  performs  as  a 
SICC. 


(35)  Unit  of  Issue.  The  Services  consistently  vali¬ 
date  this  data  element  for  an  alphabetic  entry.  The  Navy  as 
SICC  will  edit  this  data  element  to  reflect  'EA'  when  invalid. 
The  Air  Force  as  WIMM  bypasses  validation  of  this  data  element. 
DLA  validation  criteria  matches  this  data  element  against  valid 
codes  contained  in  the  DIDS  Procedures  Manual.  The  DODSSR 
Validation  Criteria  parallels  that  of  DLA. 

(36)  Unit  Price.  This  data  element  is  applicable  to 
inactive  NSN,  PSCN,  and  Part  Number  LISSR  transactions  only. 
Validation  criteria  for  this  data  element  differs  significantly 
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from  Component  to  Component.  The  Army  validation  for  inactive 
NSN  and  PSCN  LISSR  transactions  checks  for  a  value  of  spaces  or 
zero.  For  Part  Number  LISSR  transactions  the  Array  validation 
looks  for  a  numeric  entry  greater  than  zero.  The  Navy  and  Air 
Force  as  SICCs  validate  Unit  Price  for  a  numeric  entry  and  as 
WIMMs  bypass  validation  of  this  data  element.  DLA  validation 
criteria  is  tied  to  the  value  of  the  PMC.  When  the  PMC  is  space, 
the  Unit  Price  must  be  spaces;  and  when  the  PMC  equals  0  thru  5, 
the  Unit  Price  must  be  numeric.  The  DODSSR  validation  criteria 
parallels  that  of  DLA. 

c.  Catalog  Transactions.  Catalog  transactions  are  made 
up  of  Item  Name  transactions,  Additional  Reference  Number  trans¬ 
actions  and  Additional  User  transactions.  These  transactions 
are  submitted  from  SICC  to  C IMM  only. 

(1)  Activity  Code  From  (ACF).  This  data  element  is 
validated  identically  in  catalog  transactions  to  the  manner  of 
validation  in  PDSSR  transactions  described  in  subsection  III.C. 

3  .a  .  ( 1 )  above. 

(2)  Activity  Code  To  (ACT).  This  data  element  is 
validated  in  Catalog  transactions  exactly  the  same  as  it  is  in 
PDSSR  transactions  described  in  subsection  1 1 1 .  C . 3 . a  .  ( 2 )  above. 

(3)  Additional  Activity  Codes.  This  data  element 
is  validated  by  all  the  Components  except  Navy  by  matching  each 
additional  activity  code  in  the  Additional  User  transaction  to 
an  activity  code  table.  The  DODSSR  validation  criteria  also 
provides  for  checking  each  additional  activity  code  against  a 
table  of  valid  activity  codes.  The  Navy  validates  this  data 
element  for  an  alphanumeric  entry  with  no  spaces. 

(4)  Date  of  Request  (DOR).  This  data  element  is 
validated  by  the  Army  and  Air  Force  by  checking  for  a  numeric 
entry.  The  Navy  validates  this  data  element  for  a  numeric  entry 
when  the  TCC  equals  C,  D,  R,  S,  or  T;  otherwise,  it  is  automati¬ 
cally  edited  to  reflect  the  current  date  plus  14  days.  DLA 
checks  this  data  element  for  a  valid  date  (character  1  equal  to 

0  thru  9,  characters  2  thru  4  equal  to  001  thru  366).  The 
DODSSR  validation  criteria  parallels  that  of  DLA. 

(5)  Document  Availability  Code  (DAC).  This  data 
element  is  applicable  to  Additional  Reference  Number  transactions 
only.  The  Army  bypasses  validation  of  this  data  element.  The 
Navy  validates  this  data  element  for  an  entry  of  1  thru  6,  9  or 

A  thru  H.  The  Air  Force  does  not  validate  this  data  element, 
but  automatically  edits  it  to  a  value  of  '5.'  DLA  validates 
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this  data  element  for  an  entry  of  space  or  0  thru  9  and  edits 
this  field  to  reflect  space  when  invalid.  The  DODSSR  validation 
criteria  checks  this  data  element  for  a  value  of  space,  1  thru 
6,  9  or  A  thru  H. 

(6)  Document  Identifier  Code  (PIC).  This  data  ele¬ 
ment  is  validated  in  Catalog  transactions  exactly  as  it  is  in 
PDSSR  transactions  described  in  subsection  II I .C . 3 . a . ( 7 )  above. 

(7)  Federal  Supply  Classification  (FSC).  This  data 
element  is  applicable  to  Item  Name  transactions  only.  The  Army 
validates  this  data  element  for  no  spaces.  The  Navy  and  Air 
Force  validate  this  data  element  for  a  numeric  entry.  DLA  vali¬ 
dates  FSC  for  a  numeric  entry  and  also  validates  the  FSC  sub¬ 
mitted  against  a  table  of  FSCs  managed  by  the  processing  Defense 
Supply  Center  (DSC).  The  DODSSR  validation  criteria  provides 
for  a  numeric  entry  check  of  this  data  element. 

(8)  FSCM.  This  data  element  is  applicable  to  Addi¬ 
tional  Reference  Number  transactions  only.  The  Army  validates 
this  data  element  for  no  spaces.  The  Navy  validates  this  data 
element  for  an  alphanumeric  entry  containing  no  spaces  or  spe¬ 
cial  characters.  The  Air  Force  validates  this  data  element  for 
an  alphanumeric  entry.  DLA  validates  this  data  element  for  a 
numeric  entry.  The  DODSSR  validation  criteria  bypasses  valida¬ 
tion  of  this  data  element  due  to  an  alternate  usage  of  this 
field  related  to  the  DODSSR  data  collection  as  described  in 
Chapter  I  of  this  Volume. 

(9)  Item  Management  Code  (IMC).  This  data  element 
is  applicable  to  Additional  User  transactions  only.  The  Army 
validates  this  data  element  for  an  entry  not  equal  to  space. 

The  Navy  validates  this  data  element  for  an  entry  equal  to  D,  E, 
F,  H,  J,  K,  L,  M,  N,  0,  Q,  R,  S,  T,  U,  W,  or  Z.  The  Air  Force 
automatically  edits  this  data  element  to  reflect  ’Ff  or  'Z' 
depending  on  the  ACT.  DLA  validates  this  field  for  a  value  of 
'Z'  and  edits  it  to  reflect  '  Z*  when  invalid.  The  DODSSR  vali¬ 
dation  criteria  provides  for  validating  this  data  element  for  an 
entry  of  ' F '  or  ' Z . ' 

(10)  Item  Name.  This  data  element  is  applicable  to 
Item  Name  transactions  only.  This  data  element  is  consistently 
validated  for  an  alphanumeric,  lef t-justif led  entry  by  all  Com¬ 
ponents  and  the  DODSSR  validation  criteria. 

(11)  Item  Serial  Number  (ISN).  Validation  criteria 
for  this  data  element  for  Catalog  transactions  is  identical  to 
the  criteria  for  ISN  in  LISSR  transactions  described  in  subsec¬ 
tion  III .C. 3 .b . ( 15)  above. 
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(12)  Manufacturers  Reference  Number.  This  data  ele¬ 
ment  is  applicable  to  Additional  Reference  Number  transactions 
only.  Validation  criteria  for  all  Components  and  the  DODSSR 
validation  criteria  is  a  left- justified  entry  not  all  equal  to 
spaces  . 

(13)  Provisioning  Control  Code  (PCC).  This  data 
element  is  validated  in  Catalog  transactions  exactly  the  same  as 
it  is  in  PDSSR  transactions  described  in  subsection  III. C. 3. a. 

( 14 )  above . 

(14)  Reference  Number  Category  Code  (RNCC).  This 
data  element  is  applicable  to  Additional  Reference  Number  trans¬ 
actions  only.  The  Army  bypasses  validation  of  this  data  element. 
The  Navy  validates  this  data  element  for  an  entry  of  1  thru  8, 

or  A  thru  D  and  edits  this  field  to  reflect  '3'  when  invalid. 

The  Air  Force  does  not  validate  this  data  element,  but  automati¬ 
cally  edits  it  to  reflect  '3'  whenever  it  appears.  DLA  valida¬ 
tes  this  data  element  for  an  entry  of  space,  1  thru  5,  or  A  thru 
D  and  edits  the  field  to  reflect  space  when  invalid.  The  DODSSR 
^nlidation  criteria  provides  for  validating  the  RNCC  for  an 
entry  of  space,  1  thru  8  or  A  thru  D. 

(15)  Reference  Number  Format  Code  (RNFC ) .  This  data 
element  is  applicable  to  Additional  Reference  Number  transactions 
only  and  is  validated  here  using  the  same  criteria  described  in 
subsection  1 1 1 . C . 3 . b . ( 2 5 )  above. 

(16)  Reference  Number  Variation  Code  (RNVC).  This 
data  element  is  applicable  to  Additional  Reference  Number  trans¬ 
actions  only  and  is  validated  here  using  the  same  criteria  des¬ 
cribed  in  subsection  1 1 1 . C . 3  .  b . ( 27  )  above. 

(17)  Type  Change  Code  (TCC) .  This  data  element 
applies  to  Item  Name  transactions  only  and  is  validated  using 
identical  criteria  to  that  described  in  subsection  1 1 1  .C . 3 . b  .  ( 34 ) 
above  except  for  Army.  Army  validates  this  data  element  in  item 
name  transactions  for  an  entry  of  space,  T,  or  V. 

d •  Line  Item  Advice  Card  (LIAC)  Transactions.  Line 
item  advice  card  transactions  Include  advice  transactions,  offer 
reply  transactions,  followup  transactions  and  followup  response 
transactions.  As  discussed  in  the  section  on  validation  conven¬ 
tions,  the  automated  SSR  Applications  of  the  Components  are 
designed  to  generate  some  of  these  LIACs  when  conditions  permit 
or  as  a  result  of  file  maintenance  transactions,  and  these  auto¬ 
matically  generated  transactions  are  not  mechanically  validated. 
The  discussion  here  is  keyed  to  LIAC  transactions  either  manually 
generated  and  input  to  the  Component  SSR  Application  or  received 
from  another  activity  via  mail  or  AUTODIN. 
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(1)  Action  Taken  Code  (ATC).  This  data  element 

la  found  on  all  L1AC  transactions  except  followup  transactions. 
Validation  of  this  data  element  varies  significantly  from  Com¬ 
ponent  to  Component.  The  Army  validates  this  data  element  for  a 
valid  ATC.  Valid  ATCs  in  the  Army  include  not  only  the  codes 
contained  in  the  IMM  Manual,  but  also  several  Army  unique  ATCs. 

The  Navy  as  SICC  bypasses  validation  of  this  data  element  and  as 
WIMM  validates  it  for  an  entry  with  no  spaces.  The  Air  Force  as 
SICC  validates  the  ATC  for  an  alphanumeric  entry  and  as  WIMM 
examines  this  field  for  a  valid  code  from  the  IMM  Manual.  DLA 
bypasses  validation  of  this  data  element.  The  DODSSR  validation 
criteria  is  much  more  extensive  than  those  described  above. 

This  criteria  first  checks  for  a  valid  ATC  from  the  IMM  Manual 
then  goes  on  to  key  specific  validations  to  the  DIC  and  other 
data  elements.  This  additional  criteria  is  as  follows: 

*  When  the  DIC  is  CXI  (advice  transaction),  the 
ATC  cannot  be  '66.' 

*  When  the  DIC  is  CXI  or  CX4  (followup  response 
transaction)  and  the  ATC  is  YA,  YJ,  YL ,  YR,  YU,  33  or  34,  vali¬ 
date  the  NSN  field  for  a  numeric  entry. 

*  When  the  DIC  is  CXI  or  CX4  and  the  ATC  is  YW, 
validates  the  PSCN  field  for  an  alphanumeric  (0-9,  A-Z)  entry. 

*  When  the  DIC  is  CXI  or  CX4  and  the  ATC  is  YQ, 
validate  the  Manufacturer  Reference  Number  field  for  an  entry 
not  equal  to  all  spaces. 

*  When  the  DIC  is  CXI  or  CX4  and  the  ATC  is  YC 
or  60,  validate  the  FSC  field  for  a  numeric  entry. 

*  When  the  DIC  is  CXI  or  CX4  and  the  ATC  is  YA, 
YL,  or  YQ,  validate  the  YX  date  field  for  entry  of  spaces  or  a 
valid  date  (character  1  equals  0-9,  characters  2-4  equal  001-366). 

*  When  the  DIC  is  CXI  or  CX4  and  the  ATC  is  YX, 
validate  the  YX  date  field  for  a  valid  date. 

*  When  the  DIC  is  CX2 ,  the  ATC  must  equal  YM, 

YN,  YP  or  YV. 

(2)  Activity  Code  From  (ACF).  This  data  element  is 
generally  validated  by  all  Components  and  the  DODSSR  validation 
criteria  by  matching  the  ACF  to  a  table  of  valid  activity  codes 
or  in  the  case  of  outgoing  LIAC  transactions  matching  the  ACF  to 
the  activity  code  of  the  processing  activity.  The  Navy  as  SICC, 
and  DLA  bypass  validation  of  this  data  element. 


(3)  Actlvitiy  Code  To  (ACT).  This  data  element  like 
ACF  is  generally  validated  by  all  Components  and  the  DODSSR  vali¬ 
dation  criteria  by  matching  the  ACT  to  a  table  of  valid  activity 
codes  or  in  the  case  of  incoming  LIAC  transactions  matching  the 
ACT  to  the  activity  code  of  the  processing  activity.  The  Navy 
as  SICC  bypasses  validation  of  this  data  element. 


(4)  Date  of  Advice  (DOA).  The  Army  and  Air  Force 
validate  this  data  element  for  a  numeric  entry.  The  Navy  as 
SICC  and  DLA  bypass  validation  of  this  data  element.  The  Navy 
as  WIMM  does  not  validate  this  data  element,  but  automatically 
edits  the  field  to  reflect  the  current  date.  The  DODSSR  valida¬ 
tion  criteria  validates  this  data  element  for  a  valid  date 
(character  1  equal  0-9,  characters  2-4  equal  001-366). 


(5)  Date  of  Request  (DOR).  The  Army  validates  this 
data  element  for  a  numeric  entry.  The  Navy  as  SICC  bypasses 
validation  of  the  DOR  and  as  WIMM  validates  this  data  element 
for  a  numeric  entry.  The  Air  Force  as  SICC  validates  this  data 
element  for  a  numeric  entry  and  as  WIMM  bypasses  validation  of 
the  DOR.  DLA  bypasses  validation  of  this  data  element.  The 
DODSSR  validation  criteria  provides  for  checking  the  DOR  for 
entry  of  a  valid  date. 


(6)  Document  Identifier  Code  (PIC).  This  data  ele¬ 
ment  is  consistently  validated  by  all  Components  for  entry  of  a 
valid  code.  The  DODSSR  validation  criteria  bypasses  validation 
of  this  data  element  because  the  DIC  was  used  as  a  control  for 
entry  into  the  DODSSR  data  base  as  described  in  Chapter  I  of 
this  Volume. 

(7)  FSCM.  Validation  of  this  data  element  is  tied 
to  the  ATC.  Generally,  when  the  ATC  is  YQ  and  the  Manufacturers 
Part  Number  is  not  spaces  this  data  element  is  validated  for  an 
alphanumeric  entry.  The  Navy  and  DLA  bypass  validation  of  this 
data  element.  The  DODSSR  validation  criteria  bypasses  valida¬ 
tion  of  this  data  element  due  to  the  special  usage  of  this  field 
related  to  the  data  collection  described  in  Chapter  I  of  this 
Volume . 

(8)  Item  Serial  Number  (ISN).  Validation  of  this 
data  element  varies  significantly  from  Component  to  Component. 

The  Army  validates  this  data  element  for  no  space  in  characters 
1  thru  4.  The  Navy  bypasses  validation  of  ISN  as  a  SICC  and  as 

a  WIMM  validates  it  for  an  entry  not  equal  to  all  spaces;  the  Air 
Force  validation  checks  character  1  for  an  entry  not  equal  to 
space  or  a  special  character  as  a  SICC  and  bypasses  validation 
of  this  data  element  as  a  WIMM.  DLA  bypasses  validation  of  this 
data  element.  The  DODSSR  validation  criteria  checks  for  an 
alphanumeric  entry  which  is  not  equal  to  all  spaces. 
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(9)  NSN/PSCN/Manuf acturers  Reference  Number.  The 
Army  and  Air  Force  key  validation  of  this  multiple  use  field  to 
the  ATC.  When  the  ATC  is  YA,  Y J ,  YL ,  YR,  YU,  33,  or  34  a  numeric 
check  is  made  for  entry  of  an  NSN.  When  the  ATC  is  YW,  an  alpha¬ 
numeric  check  is  made  for  entry  of  a  PSCN.  When  the  ATC  is  YQ, 
an  alphanumeric  check  is  made  for  entry  of  a  Manufacturers  Part 
Number.  The  Navy  and  DLA  bypass  validation  of  this  data  ele¬ 
ment.  The  DODSSR  validation  criteria  for  this  multiple  use 
field  parallels  that  of  the  Army  and  Air  Force,  and  was  described 
under  ATC  validation  above. 

(10)  Provisioning  Control  Code  (PCC).  The  Army  vali¬ 
dates  this  data  element  for  an  entry  not  equal  to  spaces.  The 
Navy  as  a  WIMM  validates  this  data  element  for  an  alphanumeric 
entry.  The  Navy  as  SICC,  the  Air  Force  and  DLA  all  bypass  vali¬ 
dation  of  this  data  element.  The  DODSSR  validation  criteria 
validates  PCC  for  an  alphanumeric  entry. 

(11)  Type  Change  Code  (TCC).  Validation  of  TCC  in 
LIAC  transactions  is  bypassed  by  all  Components  and  the  DODSSR 
validation  criteria  except  for  Air  Force  as  a  SICC.  The  Air 
Force  as  SICC  validates  TCC  for  an  entry  of  space  or  'V'  and 
edits  the  field  to  reflect  space  when  invalid. 

(12)  YX  Date/FSC.  This  data  element  is  validated 
for  spaces  or  a  numeric  entry  by  the  Army  and  Air  Force.  The 
Navy  and  DLA  bypass  validation  of  this  data  element.  The  DODSSR 
Validation  Criteria  relating  to  this  data  element  is  keyed  to 
the  ATC  as  described  in  the  ATC  validation  above. 


4.  Automated  Edi t / Val i da t ion  Analysis 


Validation  Conventions 


Each  of  the  Components  have  designed  their  automated 
SSR  Applications  with  validation  performed  in  multiple  program 
modules.  Generally,  a  program  module  dedicated  to  SSR  validation 
at  the  package  level,  duplicate  level  and  detail  level  exists. 

Mat ch/ dup licate  validations  are  generally  imbedded  in  an  SSR 
file  maintenance  program  module.  The  PCC  package  validations 
and  LISSR  package  validations  are  generally  consistent  from 
Component  to  Component. 

Duplicate/match  validation  criteria  varies  signif¬ 
icantly  from  Component  to  Component.  The  variation  in  dupli¬ 
cate  validation  criteria  lies  in  two  areas.  First,  the  type  of 
duplicate  validation  total  card  or  control  data  element  or  both 
varies  from  Component  to  Component.  In  addition,  when  control 
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data  element  validation  is  done,  some  Components  use  different 
control  data  elements  than  others.  This  may  result  in  submis¬ 
sion  of  unique  transactions  from  a  SICC  standpoint,  but  dupli¬ 
cative  transactions  from  an  IMM  standpoint. 

The  variance  in  the  match  criteria  is  primarily  due 
to  the  difference  in  transactions  posted  to  the  Component  SSR 
Suspense  Files.  For  example,  the  Army  system  design  calls  for 
matching  all  SSR  change  transactions  by  control  elements  against 
their  SSR  Suspense  File  as  part  of  their  validation  of  these 
transactions  and  posts  these  transactions  to  the  SSR  Suspense 
File.  DLA,  on  the  other  hand,  does  not  match  these  SSR  change 
transactions  to  its  SSR  Suspense  or  SSR  History  Files,  does  not 
process  these  transactions  on  an  automated  basis  (except  for 
superceding  items),  and  does  not  post  these  transactions  to  the 
automated  SSR  Suspense  or  SSR  History  Files  (except  again  super- 
ceding  items  which  are  processed  as  initial  submittals).  Evi¬ 
dently  the  IMM  Manual  does  not  clearly  point  out  the  specific 
match/duplicate  validations  that  should  be  performed  by  all 
Components  although  it  does  provide  the  means  (in  terms  of  some 
ATCs)  to  indicate  when  duplicates  are  found  or  matches  do  not 
exist . 


All  the  Components  sort  transactions  input  to  their 
automated  system  prior  to  validation.  This  sort  is  based  on 
control  elements  contained  in  the  SSR  transactions  and  include 
ACF,  ACT,  PCC,  DOR,  ISN,  DIC,  TCC  and  Card  Number.  Most  of  the 
Components  establish  a  sort  key  or  other  control  area  and  append 
this  to  the  SSR  transaction  either  at  the  beginning  as  DLA  or  at 
the  end  as  Air  Force.  This  information  is  appended  to  these 
transactions  for  two  reasons.  First,  these  data  elements  are 
located  in  various  positions  in  the  SSR  transaction;  e.g.,  ACT 
is  in  positions  4  and  5  while  ACF  is  located  in  positions  67  and 
68.  Second,  these  data  elements  are  not  located  in  the  proper 
sort  sequence  or  for  that  matter  in  the  proper  sequence  for  entry 
into  automated  files.  If  these  data  elements  were  located  in 
contiguous  positions  and  in  the  proper  sequence,  it  would  not 
eliminate  the  sort  process  itself;  however,  it  would  insure  that 
all  Components  are  validating  these  transactions  in  the  same 
sequence  and  in  some  SSR  Applications  would  eliminate  the  require¬ 
ment  for  a  separate  program  module  to  establish  this  sort  key  as 
the  first  step  of  SSR  processing.  The  practice  of  placing  con¬ 
trol  elements  together  in  a  specific  area  in  each  transaction 
has  been  used  in  other  DoD  programs  such  as  the  Document  Control 
Number  specified  in  the  DIDS  Procedures  Manual  (Appendix  D,  Refer¬ 
ence  25)  and  the  Document  Number  used  in  Materiel  Requisitions 
and  specified  in  the  MILSTRIP  Manual  (Appendix  D,  Reference  32). 

There  are  distinct  differences  in  which  SSR  trans¬ 
actions  are  posted  to  the  SSR  Suspense  Files  of  each  Component. 
These  differences  are  evident  from  the  systems  descriptions  in 
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Volume  II  and  from  the  discussion  of  validation  conventions 
above.  These  differences  range  from  the  posting  of  valid  trans¬ 
actions  only  to  the  Component  SSR  Suspense  File  to  posting  of 
all  transactions  whether  valid  or  invalid  to  the  Component  SSR 
Suspense  File.  The  differences  also  range  from  posting  all  types 
of  SSR  transactions  to  the  Component  SSR  Suspense  File  to  posting 
of  initial  submittal  and  superceding  item  SSR  transactions  only. 
This  inconsistency  in  file  posting  makes  comparable  audit  trails 
for  SSR  transactions  impossible  and  may  cause  extensive  time 
delays  in  SSR  processing.  For  example,  an  SSR  transaction  is 
submitted  to  an  IMM,  validated  and  rejected  based  on  a  valida¬ 
tion  error.  Because  the  transaction  was  in  error,  it  is  flushed 
from  the  IMM's  automated  system  and  not  posted  to  the  SSR  Suspense 
File.  If  for  some  reason,  the  SICC  does  not  receive  the  reject 
advice  transaction  or  receives  it  beyond  the  followup  time,  the 
SICC  generates  a  followup  to  the  IMM  which  is  automatically  pro¬ 
cessed  and  assigned  an  ATC  of  '66'  (No  Record).  When  the  follow¬ 
up  response  is  received  by  the  SICC  a  resubmittal  will  be  gener¬ 
ated  and  submitted  to  the  IMM  only  to  be  rejected  for  the  same 
error  as  the  original  submission.  It  is  easy  to  see  how  some  of 
the  extended  time  frames  described  in  Chapter  I  of  this  Volume 
can  occur,  simply  because  rejected  SSR  transactions  are  not  posted 
to  the  Component  SSR  Suspense  File.  The  IMM  Manual  should  pro¬ 
vide  guidance  as  to  what  transactions  should  be  maintained  in 
automated  SSR  Suspense  Files,  the  control  data  elements  to  be 
used  for  sequencing  and  retrieval,  and  the  type  of  audit  trail 
that  should  be  maintained  for  each  item. 

The  concept  of  single  vs.  multiple  error  validation 
was  found  to  be  part  of  Navy  and  Air  Force  validation  design. 

The  exttnt  to  which  multiple  errors  occur  has  a  direct  bearing 
on  this  concept  and  was  explored  as  part  of  the  validation  of 
the  DODSSR  data  base.  The  results  of  this  validation  is  dis¬ 
cussed  below. 

b .  Data  Element  Validation  Criteria 

The  enumeration  of  the  validation  criteria  designed 
into  each  of  the  Component  automated  systems  on  a  data  element 
basis  reveals  some  interesting  concepts.  First,  most  data  ele¬ 
ments  described  as  "control"  data  element  and  "key"  data  ele¬ 
ments  are  validated  consistently  by  all  Components.  These  data 
elements  are  generally  those  required  for  processing  of  SSR 
transactions  and  include  DIC,  ACF,  ACT,  PCC,  Card  Number,  NSN, 
Replenishment  Quantity,  Retail  Quantity,  Item  Name,  FSC  and 
Manufacturers  Reference  Number.  Three  additional  data  elements 
which  fall  into  this  category,  but  are  not  validated  are  DOR, 

ISN,  and  TCC.  The  DOR  is  generally  mechanically  assigned  on 
outgoing  SSR  transactions  and  is  validated  for  a  numeric  value 
on  incoming  SSR  transactions.  The  validation  of  ISN  varies  to  a 
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larger  extent  from  Component  to  Component  and  It  may  be  easily 
seen  how  this  Inconsistency  in  validation  criteria  can  cause 
rejects  of  SSR  transactions.  The  validation  of  TCC  in  PDSSR 
transactions  is  relatively  consistent  for  all  Components;  how¬ 
ever,  for  LISSR  transactions  this  data  element  is  validated  for 
a  valid  entry  by  some  Components  while  others  tie  the  validation 
to  the  TCC  of  the  associated  PDSSR  transactions. 

Other  data  elements  are  validated  and  edited  when 
found  invalid  or  simply  edited  to  a  specific  value  without  vali¬ 
dation.  Data  elements  included  in  this  category  include  Inter¬ 
changeability  Code,  Source  Code,  IMC ,  SMCC,  Reference  Number 
Category  Code,  Reference  Number  Format  Code,  Reference  Number 
Justification  Code,  Reference  Number  Variation  Code,  Technical 
Data  Justification  Code,  and  Date  NSNs  are  Required.  Because  of 
the  extensive  amount  of  editing  performed  on  these  data  elements, 
SSR  transactions  should  not  be  rejected  for  errors  in  these  data 
elements,  and  depending  on  usage,  these  data  elements  should  be 
considered  for  elimination.  The  IMC  and  Date  NSNs  are  Required 
are  examples  of  two  data  elements  in  this  category  which  should 
be  eliminated. 

The  IMC  is  required  by  the  IMM  Manual  in  SICC  to 
CIMM  LISSR  transactions  and  is  edited  when  invalid  by  DLA.  This 
data  element  was  an  addition  to  the  SSR  procedures  with  the 
implementation  of  the  IMM  Manual.  The  procedures  in  effect  prior 
to  1  May  1978  did  not  contain  IMC  as  a  data  element  and  each  SSR 
transaction  was  considered  an  IMC  transaction  also.  This  proce¬ 
dure  should  apply  to  the  IMM  Manual  considering  that  within  the 
DoDSSR  data  base  this  data  element  was  found  to  be  invalid  in 
only  0.5%  of  the  transactions  in  which  it  is  required. 

The  Date  NSNs  are  Required  is  used  when  NSNs  for 
Part  Number  SSRs  are  required  in  less  than  60  days.  This  data 
elem.it  is  edited  when  invalid  by  three  Components.  Validation 
of  this  data  element  in  the  DODSSR  data  base  revealed  that  an 
entry  was  made  in  only  5.2%  of  all  PDSSR  transactions  and  was 
invalid  in  63.1%  of  the  transactions  containing  an  entry.  In 
addition.  Chapter  I  of  this  Volume  indicated  the  average  time 
entered  in  this  data  element  (when  valid)  is  55  days.  The  use¬ 
fulness  of  this  data  element  is  questionable  when  considering 
these  factors.  The  differences  in  the  percentages  expressed 
here  and  those  shown  in  Chapter  I  of  this  Volume  are  due  to 
sample  size  and  validation  criteria  applied. 

A  third  category  of  data  elements  are  those  which 
are  not  validated,  but  bypassed.  These  include  Item  Identifi¬ 
cation  Data  Collaborator,  Item  Identification  Data  Receiver  and 
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Materiel  Management  Aggregation  Code.  These  data  elements  are 
limited  to  SICC  to  WIMM  SSR  transactions.  The  use  of  these  data 
elements  should  be  reviewed  to  determine  their  potential  for 
elimination  from  the  SSR  procedures. 

The  remaining  data  elements  have  validation  criteria 
which  varies  from  Component  to  Component.  These  data  elements 
are  reviewed  in  terms  of  their  individual  errors  rates  from 
validation  of  the  DODSSR  data  base  below. 

D.  DODSSR  DATA  BASE  VALIDATION 

1 .  General 

This  section  discusses  the  DODSSR  validation  conventions 
and  the  application  of  the  DODSSR  validation  criteria  to  the 
DODSSR  data  base.  The  DODSSR  validation  criteria  although  applied 
in  a  five-level  structure  as  discussed  above  contains  more  than 
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a .  Control  Data  Elements  (Mandatory) 

*  Activity  Code  From 

*  Activity  Code  To 

*  Document  Identifier  Code 

*  Date  of  Request 

*  Item  Serial  Number 

*  Provisioning  Control  Code 

b .  Key  Data  Elements  (Mandatory) 

*  FSCM 

*  Manufacturers  Reference  Number 

*  NSN 

*  Procurement  Method  Code 

*  PSCN 

*  Unit  of  Issue 

*  Unit  Price 
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c .  Other  Mandatory  Data  Elements 


*  Action  Taken  Code 

*  Additional  Activity  Code 

*  Card  Number 

*  Contract  Control  Number 

*  Date  of  Advice 

*  Date  Repair  Parts  Required 

*  Demilitarization  Code 

*  End  Item  Delivery  Code 

*  End  Item  NSN,  Name,  etc. 

*  End  Item  Quantity 

*  Federal  Supply  Classification 
'  *  Item  Management  Code 

*  Item  Name 

*  Number  of  SSRs  Enclosed 

*  Percent  End  Items  East 

*  Production  Leadtime 

*  '  antity  Per  End  Item 

*  Replenishment  Quantity 

*  Retail  Quantity 

*  Shelf  Life  Code 

*  Source  Code 

*  Special  Material  Content  Code 

*  Type  Change  Code 

d.  Conditional  Data  Elements 


*  Acquisition  Advice  Code 

*  Date  Technical  Data  to  be  Supplied 

*  Document  Availability  Code 

*  Interchangeability  Code 

*  Item  Identification  Data  Collaborator 

*  Item  Identification  Data  Receiver 

*  Materiel  Management  Aggregation  Code 

*  Reference  Number  Category  Code 

*  Reference  Number  Format  Code 

*  Reference  Number  Justification  Code 

*  Reference  Number  Variation  Code 

*  Technical  Data  Justification  Code 

e .  Optional  Data  Elements 

*  Date  NSNs  are  Required 

*  Weapons  System  Code 

The  DODSSR  Validation  Criteria  provides  for  validation 
of  each  data  element  listed  above  with  each  data  element  assigned 
a  separate  reject  code  except  for  those  data  elements  contained 
in  the  edit  portion.  Several  data  elements  due  to  their  apparent 
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validation  and  usage  by  the  Components  were  selected  to  produce 
editing  statistics  rather  than  validation  reject  statistics. 
These  "edited''  data  elements  are  listed  below  with  their  respec¬ 
tive  level  in  parentheses. 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


Item  Management  Code  (Other  Mandatory) 

Number  of  SSRs  Enclosed  (Other  Mandatory) 

Special  Material  Content  Code  (Other  Mandatory) 

Date  Technical  Data  to  be  Supplied  (Conditional) 
Document  Availability  Code  (Conditional) 

Item  Identification  Data  Collaborator  (Conditional) 
Item  Identification  Data  Receiver  (Conditional) 
Interchangeability  Code  (Conditional) 

Materiel  Management  Aggregation  Code  (Conditional) 
Reference  Number  Category  Code  (Conditional) 
Reference  Number  Format  Code  (Conditional) 

Reference  Number  Variation  Code  (Conditional) 
Technical  Data  Justification  Code  (Conditional) 

Date  NSNs  are  Required  (Optional) 

Weapons  System  Code  (Optional) 
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2 .  PDSSR,  LISSR,  and  Catalog  Transaction  Validation  Reject 
Analysis 


The  validation  error  percentages  by  Service  are  shown  in 
Figure  III-l.  The  first  column  represents  the  invalid  data  error 
volumes  actually  experienced  for  the  Steady  State  Period  Popula¬ 
tion  and  presented  in  Chapter  I  of  this  Volume,  Figure  1-57.  The 
second  column  shows  the  error  volumes  experienced  by  each  Service 
as  a  result  of  the  DODSSR  validation  criteria. 


Note  the  general  consistency  in  percentages  for  each  Com¬ 
ponent  (except  Navy)  between  the  two  sets  of  error  volumes.  This 
same  consistency  is  present  on  an  activity  basis  except  at  ASO, 
and  indicates  that  applying  the  DODSSR  validation  criteria  to  the 
DODSSR  data  base  reflects  the  volumes  and  types  of  errors  actually 
being  experienced  in  the  System.  The  higher  percentage  in  the  Navy 
is  attributable  to  ASO  where  a  higher  percentage  of  PCC  package 
errors  was  identified  by  the  DODSSR  Validation  than  was  apparent 
from  the  Data  Collection.  This  difference  in  volume  of  PCC  package 
errors  identified  is  primarily  due  to  the  manual  corrections  of 
package  errors  at  some  IMM  activities  and  the  nonsubmittal  of  cer¬ 
tain  PCC  package  errors  to  the  study  team  during  the  Data  Collection 


period.  These  PCC  package  errors  are  Identified  by  ATC  '51'  (Valid 
PDSSR,  no  LISSRs)  and  are  not  returned  in  a  reject  advice  transac¬ 
tion  by  DLA,  but  by  a  mailed  listing  on  which  ATC  '51*  has  been 
annotated . 

VALIDATION  ERROR  VOLUMES  BY  SERVICE 
LISSR  TRANSACTIONS  COLUMN  PERCENT 


SICC 

Error  Volumes 
Experienced 

DODSSR 
Validation 
Error  Volumes 

Army 

17.5 

17.8 

Navy 

30.6 

43.0 

Air  Force 

30.4 

26.7 

Marine  Corps 

8.5 

4.2 

Coast  Guard 

1.0 

0.8 

Other 

12.0 

7.5 

Source:  DODSSR  Data  Collection;  Steady  State  Period 

Population 

Figure  III-l 

a.  Validation  Level  Analysis.  The  validation  error 
volumes  by  level  for  all  SSR  transactions  are  shown  in  Figure 
III-2. 

VALIDATION  ERROR  VOLUMES  BY  LEVEL 
(All  DICs) 


Validation  Level 

Percent  Error 

PDSSR  Package 

36.3 

LISSR  Package 

6.0 

Duplicate 

31.4 

Control  Data  Element 

1.4 

Key  Data  Element 

6.8 

Other  Mandatory  Data  Element 

17.3 

Conditional  Data  Element 

0.8 

Source:  DODSSR  Data  Collection;  Main  Population 
Figure  I I I- 2 

This  figure  shows  that  85%  of  the  errors  are  located  in  three 
levels.  The  PCC  package  validation  level,  duplicate  validation 
level  and  other  mandatory  data  element  validation  level.  As  dis¬ 
cussed  above  the  volume  of  duplicate  errors  is  artiflcally  high 
and  will  therefore  not  be  discussed  further.  Also,  many  of  these 
duplicate  errors  are  for  LIAC  transactions  which  are  not  routinely 
validated  prior  to  submittal.  However,  as  seen  in  the  discussion 
of  validation  criteria  above,  the  Components  subject  PDSSR,  LISSR, 
and  Catalog  transactions  to  extensive  validation  prior  to  submis¬ 
sion  in  their  automated  systems  design.  The  validation  error 


volumes  by  DIC  for  each  validation  level  are  shown  in  Figure  III-3. 
From  this  figure,  it  is  clear  that  the  high  error  volumes  are  oc¬ 
curring  in  the  package,  duplicate  and  other  mandatory  data  element 
validation  levels.  The  percent  of  key  data  element  errors  for 
CXA/CXC  transactions  is  also  significantly  high. 

(1)  PDSSR  Transactions.  As  shown  in  Figure  III-3 
the  major  contributor  to  errors  in  PDSSR  transactions  is  the 
package  validations  performed.  The  zero  percentages  at  the  LISSR 
package,  key  data  element  and  conditional  data  element  valida¬ 
tion  levels  is  not  surprising.  LISSR  package  validation  does 
not  apply  to  PDSSR  transactions  and  these  transactions  contain 

no  key  data  elements  or  conditional  data  elements  to  validate. 
Examination  of  validation  levels  by  Components  and  activity 
reveals  the  same  pattern  of  error  volumes  for  PDSSR  transations. 

(2)  LISSR  Transactions.  Figure  III-4  shows  the 
validation  error  volumes  by  Component  for  all  LISSR  transactions. 

As  shown  by  this  figure,  all  Components  have  high  percentages  in 
the  PCC  package  category;  however,  the  errors  in  the  Navy  are 
predominated  by  the  PCC  package  level.  The  Army  has  significant 
error  volumes  at  the  LISSR  package  and  key  data  element  valida¬ 
tion  levels  as  well  as  the  PCC  package  validation  level.  The 
other  mandatory  data  element  validation  level  contains  the 
largest  percentage  of  errors  in  the  Air  Force  with  PCC  package 
errors  and  key  data  element  error  volumes  showing  significant 
percentages.  The  Marine  Corps  has  the  majority  of  its  errors  in 
the  PCC  package,  LISSR  package  and  other  mandatory  data  element 
validation  levels.  The  Coast  Guard  shows  errors  primarily  in 
the  PCC  package  and  other  mandatory  data  element  validation 
levels. 

VALIDATION  ERROR  VOLUMES  BY  COMPONENT 
LISSR  TRANSACTION  COLUMN  PERCENT 


Validation  error  volumes  by  Service  for  catalog 
transactions  is  shown  in  Figure  III-5.  This  figure  again  shows 
the  predominance  of  errors  in  the  package  validation  levels.  The 
high  incidence  of  duplicate  errors  in  the  Army  and  Air  Force  is 
primarily  due  to  the  DODSSR  validation  criteria  as  explained 
above.  Note  the  high  percentage  of  other  mandatory  data  element 
errors  in  the  Navy  in  Figure  III-5. 


VALIDATION  ERROR  VOLUMES  BY  COMPONENT 
CATALOG  TRANSACTIONS  COLUMN  PERCENT 
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Figure  III-5 

The  LISSR  package  errors  and  other  mandatory  data  element  errors 
for  catalog  transactions  in  the  Navy  are  97.8  percent  SPCC  errors. 
During  the  data  collection,  the  outgoing  SSR  Application  in  the 
Navy  had  been  implemented  by  ASO ,  but  not  by  SPCC.  When  this 
application  is  implemented  by  SPCC,  these  errors  should  be  greatly 
reduced.  This  figure  also  indicates  the  Marine  Corps  has  13.6% 
of  its  errors  in  control  data  elements.  The  majority  of  the  17.4% 
LISSR  package  errors  are  probably  a  direct  follow-on  of  these 
control  data  element  errors. 

From  this  validation  level  analysis,  the  volume 
of  errors  found  occur  at  four  validation  levels  -  PCC  package, 

LISSR  package,  key  data  element  and  other  mandatory  data  element. 
The  specific  data  element  error  codes  must  be  examined  to  determine 
exactly  which  data  elements  are  causing  these  errors. 

b .  Validation  Reject  Code  Analysis 

The  frequency  of  occurrence  for  reject  codes  shows 
which  error  conditions/data  elements  are  causing  the  majority  of 


errors.  The  reject  codes  are  not  shown  here,  however,  the  error 
condition/data  element  found  In  error  and  the  relative  volume 
expressed  as  a  percentage  are  listed  below. 

*  LISSR  transactions  or  Catalog  transaction  package 

error  -  39.7% 

*  Duplicate  transaction  (except  PDSSR  transactions) 

-  30.8% 

*  Procurement  Method  Code  -  5.6% 

*  Demilitarization  Code  -  3.1% 

*  Production  Leadtime  -  3.0% 

*  Shelf  Life  Code  -  3.0% 

*  Source  Code  -  1.6% 

*  Action  Taken  Code  -  1.5% 

*  Valid  PDSSR/No  LISSR  -  1.5% 

*  PDSSR  package  -  1.0% 

Note  that  while  all  package  errors  appear  as  significant  error 
percentages,  no  control  data  elements  and  only  one  key  data  ele¬ 
ment  (PMC)  appear.  This  result  is  consistent  with  the  results 
from  Chapter  I  of  this  Volume.  The  top  ten  reject  codes  in  Chap¬ 
ter  I  of  this  Volume  included  three  reject  codes  from  the  invalid 
data  category.  These  reject  codes  indicated  PCC  package  errors, 
LISSR  package  errors  and  Unit  Price  errors;  i.e.,  package  errors 
and  one  key  data  element.  The  results  are  consistent  even  in 
the  key  data  element  error  because  the  validation  of  PMC  and  Unit 
Price  is  tied  -ogether  both  by  DLA  and  in  the  DODSSR  validation 
criteria.  This  error  condition  occurs  because  the  presence  or 
absence  of  these  data  elements  is  used  by  DLA  to  distinguish 
between  active  NSN  LISSR  transactions  and  inactive  NSN  LISSR 
transactions.  Unit  Price  appeared  in  Chapter  I  c-f  this  Volume, 
while  PMC  appeared  in  the  DODSSR  validation  simply  because  of 
the  sequence  of  validation  of  these  data  elements  and  how  the 
resulting  error  condition  is  expressed. 

When  the  reject  code  percentages  are  viewed  from  a 
Component  basis,  the  data  elements  causing  the  high  percentages 
in  the  validation  levels  discussed  earlier  become  readily 
apparent.  Validation  errors  constituting  over  1%  of  the  volume 
of  errors  by  Service  are  shown  in  Figure  III-6. 

The  only  PDSSR  error  appearing  significant  overall 
is  package  errors  due  to  the  low  volume  of  PDSSR  transactions 
as  compared  to  the  volume  of  LISSR  transactions.  Therefore,  an 
analysis  of  PDSSR  transaction  errors  alone  must  be  made  to 
determine  the  PDSSR  data  elements  causing  errors.  A  review  of 
PDSSR  reject  codes  shows  that  almost  60%  of  the  PCC  package 
errors  encountered  for  PDSSR  transactions  are  valid  PDSSR  trans¬ 
actions  without  any  valid  LISSR  transactions.  Also  only  8.2% 
of  the  PDSSR  transactions  having  data  elements  in  error,  had  one 
or  more  control  data  element  errors.  The  remainder  (about  92%) 


had  other  mandatory  data  elements  In  error  of  which  DRPR  and  End 
Item  NSN,  Name,  etc.,  were  the  leading  data  elements  with  28.7% 
and  22.9%,  respectively.  Of  the  about  40%  PDSSR  transaction 
errors  due  to  duplicates  and/or  data  element  errors  68.6%  were 
data  element  errors.  The  implementation  of  the  automated  SSR 
Applications  should  improve  the  valid  PDSSR/in valid  LISSR  prob¬ 
lem  encountered.  The  use  of  the  Other  Mandatory  data  elements 
in  PDSSR  transactions  must  be  reviewed  to  determine  if  these 
elements  may  be  eliminated  or  edited  to  reduce  the  number  of 
errors  occurring  at  this  validation  level. 

VALIDATION  ERRORS  BY  ERROR  CODE 
SERVICE  COLUMN  PERCENT 
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Note:  In  this  Figure  indicates  less  than  1.0%. 


Figure  1 1 1-6 

The  high  number  of  key  data  element  errors  in  LISSR 
transactions  is  due  to  Procurement  Method  Code  which  ranks  third 
in  terms  of  error  percentage  behind  package  and  duplicate  errors 
In  the  Army,  Navy  and  Air  Force;  and  ranks  sixth  in  tne  Marine 
Corps.  Source  Code  also  provides  a  significant  percentage  of 
errors,  and  in  the  Marine  Corps,  this  other  mandatory  data  element 
ranks  second  behind  package  errors.  In  the  Air  Force  the  signif¬ 
icant  number  of  errors  for  LISSR  transactions  at  the  other  man¬ 
datory  data  element  validation  level  is  due  to  three  data  elements 


(Demilitarization  Code,  Production  Leadtime  and  Shelf  Life  Code) 
each  of  which  have  error  percentages  in  the  9-10%  range  in  the 
Air  Force. 


The  volume  of  other  mandatory  data  elements  causing 
the  significant  volume  of  errors  in  Navy  Catalog  transactions 
are  Item  Name  and  FSC  both  of  which  appear  in  Item  Name  transac¬ 
tions  (DIC  =  CXF).  The  significant  percentage  of  control  data 
element  errors  for  catalog  transactions  in  the  Marine  Corps  is 
apparently  due  to  Item  Serial  Number  errors  which  ranks  fifth  in 
this  Service.  The  volume  of  errors  for  these  data  elements  in 
these  Services  is  probably  due  to  the.  manual  processing  per¬ 
formed  by  these  Services  and  the  lack  of  automated  validation 
during  the  data  collection  period. 

All  error  conditions  identified  within  the  DODSSR 
validation  criteria  for  PDDSR,  LISSR  and  catalog  transactions 
were  found  within  the  DODSSR  data  base;  however,  seven  error 
conditions  had  volumes  less  than  0.1%.  One  control  data  element 
(Activity  Code  To)  fell  in  this  category.  Two  key  data  elements 
(Manufacturers  Reference  Number  and  Permanent  System  Control 
Number)  fell  into  this  category.  The  other  four  error  conditions 
are  for  other  mandatory  data  elements  and  include  Type  Change 
Code,  Additional  Activity  Code  on  an  Additional  User  transac¬ 
tion,  Replenishment  Quantity  and  the  Retai 1 /Replenishment  com¬ 
bination  . 


c.  Edited  Data  Elements 


Certain  data  elements  were  selected  for  editing  in 
the  DODSSR  validation  criteria  rather  than  strict  validation  and 
assignment  of  a  reject  code.  These  data  elements  were  not  actu¬ 
ally  edited  or  changed  by  the  validation  criteria,  but  counts 
were  made  of  the  number  of  times  the  data  element  was  blank,  how 
many  times  it  was  valid,  and  how  many  times  it  was  in  error. 

Each  of  these  data  elements  will  be  discussed  in  turn. 

(1)  Number  of  SSRs  Enclosed.  This  data  element  was 
found  to  be  invalid  in  0.2%  of  all  PDSSR  transactions  and  74.2% 
of  these  invalid  entries  were  blank. 

(2)  Item  Management  Code.  This  data  element  was 
found  to  be  invalid  in  only  0.5%  of  the  transactions  in  which 
it  i s  re  qu i re  d . 

(3)  Special  Material  Content  Code.  This  mandatory 
data  element  was  invalid  in  31.7%  of  the  LISSR  transactions  in 
which  it  is  required.  In  addition,  98.5%  of  the  invalid  entries 
were  spaces  . 


(4)  Item  Identification  Data  Receiver.  This  data 
element  is  to  be  used  in  Army  and  Navy  WIMM  transactions  only. 
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The  Navy  is  allowed  to  enter  two  Item  Identification  Data  Re¬ 
ceivers  while  the  Army  is  allowed  one  entry.  An  entry  was  made 
for  the  first  Item  Identification  Data  Receiver  in  each  case. 

The  Navy  placed  a  second  entry  in  14.8%  of  its  WIMM  LISSR  trans¬ 
actions. 


(5)  Item  Identification  Data  Collaborator.  This 
data  element  is  similar  in  use  to  the  item  identification  data 
receiver  above  and  the  actual  usage  for  the  first  occurrence  is 
identical;  however,  a  second  entry  was  required  only  5.6%  of  the 
time  by  the  Navy  for  this  data  element. 

(6)  Materiel  Management  Aggregation  Code.  This 
data  element  is  unique  to  the  Air  Force  and  appeared  in  11.8%  of 
this  Service's  WIMM  LISSR  transactions. 

(7)  Interchangeability  Code.  This  data  element  was 
found  to  be  invalTd  in  0.1%  of  all  LISSR  transactions. 

(8)  Reference  Number  Format  Code.  This  data  ele¬ 
ment  was  found  to  contain  an  invalid  entry  in  0.2%  of  the  appli¬ 
cable  SSR  transactions  and  was  left  blank  10.6%  of  the  time. 

(9)  Reference  Number  Category  Code.  This  data  ele¬ 
ment  was  left  blank  in  9.8%  of  the  applicable  SSR  transactions 
and  was  Invalid  in  less  than  0.1%  of  these  transactions. 

(10)  Reference  Number  Variation  Code.  This  data 
element  was  left  blank  in  9.9%  of  the  applicable  SSR  transac¬ 
tions  and  was  Invalid  in  0.2%  of  these  transactions. 

(11)  Document  Availability  Code.  This  data  element 
contained  an  invalid  entry  in  3.0%  of  the  applicable  transac¬ 
tions  and  was  left  blank  9.9%  of  the  time. 

(12)  Date  Technical  Data  To  Be  Supplied.  This  data 
element  was  left  blank  95.3%  of  the  time  and  contained  an  invalid 
entry  in  0.1%  of  the  applicable  SSR  transactions. 

(13)  Technical  Data  Justification  Code.  This  data 
element  was  left  blank  in  64.0%  of  the  applicable  SSR  transac¬ 
tions  and  was  invalid  in  less  than  0.1%  of  these  transactions. 

(14)  Date  NSNs  Required.  The  results  for  this  data 
element  were  discussed  above. 

(15)  Weapons  System  Code.  This  data  element  con¬ 
tained  an  entry  in  7.1%  of  PDSSR  transactions  and  was  Invalid  in 
6.3%  of  the  PDSSR  transactions  containing  an  entry. 

Except  for  SMCC,  DTDS,  TDJC  and  Date  NSNs  are  Re¬ 
quired,  the  low  percent  ■.«,*  of  errors  in  conjunction  with  the 
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extensive  amount  of  editing  and  bypassing  of  validation  for 
these  data  elements  indicated  that  each  of  these  data  elements 
should  be  reviewed  for  elimination  or  at  the  minimum  editing; 
i.e.,  an  SSR  transaction  should  not  be  rejected  for  an  invalid 
condition  in  any  of  these  data  elements*  The  same  is  true  for 
the  four  data  elements  mentioned  above.  The  SMCC  is  edited  by 
each  Component  when  found  to  be  invalid.  Since  it  was  found  to 
be  invalid  in  over  30Z  of  the  transactions  in  which  it  is  re¬ 
quired  the  relative  utility  of  this  data  element  is  questionable. 
An  invalid  entry  in  Date  Technical  Data  to  be  Supplied  also 
should  not  cause  rejection  due  to  the  low  error  rate  and  the 
minimal  usage  of  this  data  element.  This  is  also  true  of  Tech¬ 
nical  Data  Justification  Code.  The  relative  use  and  usefulness 
of  the  Date  NSNs  are  Required  was  discussed  above  in  the  Auto¬ 
mated  Edit/Validation  Analysis  section. 

3 .  L1AC  Validation  Reject  Analysis 

LI  AC  rejects  are  dominated  by  duplicate  errors.  This 
domination  is  due  to  the  eight  month  cycle  covered  by  the  data 
collection  and  is  illustrated  by  Figure  III-7.  It  is  important 
to  note  that  these  duplicate  transactions  are  not  all  invalid, 
but  appear  to  be  invalid  due  to  this  eight-month  cycle.  The 
transactions  in  error  shown  here  are  primarily  offer  reply  and 
followup  transactions  for  the  Services,  and  advice  and  followup 
response  transactions  for  DLA  and  GSA.  Figure  III-7  indicates 
that  while  the  Services  and  GSA  have  the  majority  of  their  errors 
appearing  in  the  control  data  element  and  other  mandatory  data 
element  validation  levels,  DLA  shows  significant  error  volumes 
in  the  key  data  element  and  other  mandatory  data  element  valida¬ 
tion  levels. 

VALIDATION  ERROR  VOLUMES  FOR  LIAC  TRANSACTIONS 
COMPONENT  COLUMN  PERCENT 
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JL/  PCC  Package,  LISSR  Package,  and  Conditional  Data  Element 
errors  do  not  occur  for  LIAC  Transactions. 

Figure  III-7 
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Since  specific  error  codes  are  not  broken  out  by  type  transac¬ 
tion  the  Service  voluaes  in  these  validation  levels  cannot  be 
analyzed  separately  froa  other  SSR  transac tions .  However,  since 
alaost  all  of  DLA's  transactions  and  all  of  GSA's  transactions 
are  advice  and  followup  response  transactions,  specific  error 
codes  may  be  analyzed  for  these  Components. 

When  specific  error  codes  are  analyzed  for  DLA,  a  single 
key  data  element  predominates  the  errors  at  this  level  with  3.3% 
of  the  total  errors.  An  NSN  is  required  in  advice  transactions 
or  followup  response  transactions  when  certain  Action  Taken 
Codes  are  used.  The  appearance  of  a  significant  error  rate  for 
this  data  element  also  validates  the  complaint  made  by  some 
activities  during  the  field  research  that  DLA  does  not  always 
provide  an  NSN  in  LIAC  Transactions  when  required  by  the  IMM 
Manual.  Other  mandatory  data  elements  causing  the  volumes  of 
error  at  this  level  for  DLA  include  Date  of  Advice  and  Action 
Taken  Code.  11.8%  of  DLA  transactions  in  error  contained  an 
invalid  Date  of  Advice  and  6.2%  contained  an  invalid  Action 
Taken  Code.  During  the  data  collection  DLA  encountered  an 
internal  system  problem  where  an  internally  used  ATC  was  being 
disseminated  mistakenly  to  SICCs.  This  problem  was  corrected  by 
DLA  and  the  ATC  errors  shown  here  are  primarily  due  to  this 
system  problem. 

The  errors  for  GSA  are  readily  apparent  when  examining 
specific  error  codes.  The  PCC,  a  control  data  element,  shows  a 
volume  of  4.1%  of  GSA  errors.  The  significant  volume  of  errors 
in  the  other  mandatory  data  element  validation  level  for  GSA  is 
due  to  Date  of  Advice  which  shows  a  9.6%  reject  volume  for  this 
Component . 

One  error  condition  for  LIAC  transactions  did  not  occur. 
This  error  condition  is  that  the  Action  Taken  Code  cannot  be  '66' 
(no  record)  when  the  DIC  equals  CXI  (advice  transactions).  In 
addition,  two  error  conditions  had  volumes  less  than  0.1%.  These 
error  conditions  are: 

*  Card  columns  77-80  must  be  blank  or  a  valid  date  when 
the  DIC  is  CXI  or  CX4  and  the  ATC  is  YA,  YL,  or  YQ. 

*  When  the  DIC  is  CX2 ,  the  ATC  must  be  YM,  YN ,  YP ,  or  YV. 

The  occurrence  of  data  element  errors  in  LIAC  transactions 
indicates  that  these  transactions  do  require  validation  prior  to 
submission.  This  is  particularly  true  of  those  which  are  manually 
generated.  LIAC  transactions  should  also  be  validated  when  re¬ 
ceived  even  though  the  IMM  Manual  currently  provides  a  method  of 
Identifying  errors  encountered  to  the  LIAC  submitter  only  for 
offer  reply  transactions. 


4.  Multiple  Validation  Considerations 


The  Navy  and  Air  Force  have  designed  multiple  error  vali 
datlon  and  identification  into  their  respective  automated  SSR 
Applications.  This  multiple  error  validation  was  described 
earlier  in  this  Chapter  and  was  the  basis  for  identification  of 
multiple  errors  during  validation  of  the  DODSSR  data  base.  Mul¬ 
tiple  error  validation  of  the  DODSSR  data  base  was  performed  to 
determine  the  potential  of  expanding  this  concept  to  provide  the 
capability  to  identify  multiple  validation  errors  as  part  of  the 
IMM  Manual.  Three  reports  will  be  presented  and  discussed  in 
relation  to  this  concept. 

The  distribution  of  number  of  errors  per  record  by  SICC 
is  shown  in  Figure  111-8. 
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Source:  DODSSR  Data  Collection;  Main  Population. 


Figure  III-8 

All  SICCs  except  Air  Force  show  better  than  95%  of  the  records 
in  error  have  less  than  four  errors  per  record  and  in  the  Army 
and  Navy  99%  of  the  records  in  error  have  three  or  less  errors 
per  record.  The  Air  Force  has  over  16%  of  its  records  in  error 
having  four  or  more  errors  per  record.  Quite  frankly  this  re¬ 
sult  is  surprising,  considering  that  the  Air  Force  was  the  only 
Service  that  had  implemented  its  automated  SSR  Application  for 
the  entire  data  collection  period  and  was  automatically  vali¬ 
dating  SSR  transactions  for  multiple  error  conditions  as  stan¬ 
dard  procedure. 


The  next  series  of  figures  shows  the  distribution  of 
number  of  errors  per  record  by  validation  level  by  type  SSR 
transaction.  The  distribution  for  PDSSR  transactions  is  shown 
in  Figure  III-9.  As  shown  by  this  figure  59. 3%  of  the  PDSSR 
transactions  in  error  had  a  PCC  package  error  only;  33. 7%  had  a 
PCC  package  error  plus  an  error  at  one  other  validation  level; 
and  the  remainder  had  a  PCC  package  error  plus  multiple  errors 
at  one  or  more  other  validation  levels.  This  figure  shows  some 
interesting  percentages  and  relationships  that  occur  only  for 
PDSSR  transactions  and  are  not  present  in  the  distributions  for 
LXSSR  catalog,  or  LIAC  transactions.  These  relationships  occur 
as  a  direct  result  of  the  PDSSR  validation  criteria;  i.e.,  if  a 
PDSSR  transaction  contains  a  duplicate,  control  data  element  or 
other  mandatory  data  element  error,  it  automatically  contains  a 
PCC  package  error  also.  This  means  that  a  PDSSR  transaction  can 
contain  a  single  error  only  when  a  PDSSR  transaction  is  not 
accompanied  by  a  valid  LISSR  transaction;  and  this  is  a  PCC  pack¬ 
age  error.  As  shown  in  the  figure  this  type  of  error  made  up 
over  59%  of  the  total  PDSSR  errors  encountered.  There  is  also  a 
direct  relationship  between  the  total  column  and  the  PCC  package 
column.  In  the  two  errors  per  record  row,  it  is  shown  that  about 
34%  of  the  total  PDSSR  transaction  in  error  contained  two  errors. 
Because  of  the  validation  criteria  one  of  these  two  errors  was  a 
PCC  package  error.  The  second  error  was  a  duplicate,  control 
data  element  or  other  mandatory  data  element  error.  Using  the 
three  errors  per  record  row,  the  total  column  shows  that  of  the 
PDSSR  transactions  in  error  over  five  percent  had  three  errors 
per  record.  Again  due  to  the  validation  criteria  one  of  these 
three  errors  was  a  PCC  package  error  and  the  remaining  two  errors 
were  a  combination  of  duplicate,  control  data  element  and/or 
other  mandatory  data  element  errors.  This  explains  the  direct 
correlation  between  the  PCC  package  and  total  column  for  this 
f igure  . 

Figure  III-10  shows  the  distribution  for  LISSR  transac¬ 
tions.  This  figure  shows  that  64.2%  of  the  LISSR  transactions 
in  error  had  a  single  error  at  one  validation  level.  This  is 
particularly  significant  when  88.4  percent  of  these  errors  are 
PCC  package  errors  meaning  that  the  LISSR  transaction  is  valid, 
but  the  accompanying  PDSSR  was  invalid.  Similarly  22.2%  of  the 
LISSR  transactions  in  error  contained  two  errors  and  of  this 
22.2%,  93%  contained  a  PCC  package  error  and  one  other  error. 

Note  that  the  highest  moan  number  of  errors  is  4.1  errors  per 
record  at  the  other  mandatory  data  element  validation  level. 

The  distribution  of  number  of  errors  per  record  for  catalog 
transactions  is  shown  in  Figure  111-11.  Note  that  the  majority 
of  records  with  one  or  two  errors  have  package  and/or  duplicate 
errors  and  that  data  element  errors  do  not  become  significant 
until  three  or  more  errors  per  record  is  reached.  This  is  also 


Illustrated  by  the  mean  of  over  three  errors  per  record  for  the 
Control  data  element  and  other  mandatory  data  element  validation 
levels.  Figure  III-12  shows  the  distribution  for  LIAC  transac¬ 
tions.  Note  that  almost  91%  of  the  LIAC  transactions  in  error 
contained  a  single  error  and  that  these  are  primarily  duplicate 
errors.  Due  the  extended  processing  cycle  involved  and  the  re¬ 
sulting  appearance  of  duplicate  errors  for  LIAC  transactions, 
these  transactions  cannot  be  subjected  to  as  stringent  an  analy¬ 
sis  as  those  contained  in  Figures  III-9,  III-10,  and  III-ll; 
however,  it  may  be  surmised  that  most  LIAC  transactions  contain 
a  single  error  by  examining  the  figure  and  evaluating  the  impact 
of  eliminating  duplicate  transaction  errors  from  the  analysis. 

The  distribution  of  the  number  of  errors  per  validation 
level  for  PDSSR  transactions,  LISSP.  transactions,  Catalog  trans¬ 
actions  and  LIAC  transactions  are  shown  in  Figures  III-13,  III-14, 
III-15,  and  III-16  respectively.  Since  only  one  PCC  package, 

LISSR  package  or  Duplicate  validation  level  error  may  occur  per 
record,  these  show  100%  in  the  one  error  per  record  row  in  each 
of  these  figures.  Figure  III-13  shows  that  one  validation  level 
error  per  record  occurs  for  most  control  data  element  errors, 
but  over  10%  of  the  records  with  other  mandatory  data  elements 
in  error  have  at  least  two  of  these  data  elements  in  error.  The 
distribution  for  LISSR  transactions  shows  essentially  the  same 
pattern  in  Figure  III-14  except  that  the  other  mandatory  data 
element  validation  level  has  almost  54%  with  three  data  elements 
at  this  level  in  error.  Figure  III-15  illustrates  that  catalog 
transactions  generally  have  two  other  mandatory  data  elements  in 
error  when  errors  occur  at  that  validation  level.  Figure  III-16 
illustrates  that  generally  LIAC  transactions  contain  one  error 
per  record  for  a  given  validation  level;  however,  the  control 
data  element  and  other  mandatory  data  element  validation  levels 
do  show  significant  percentages  at  the  two  errors  per  record 
level . 


The  frequency  of  appearance  of  multiple  errors  per  record 
indicates  that  multiple  error  validation  and  some  means  of  con¬ 
veying  multiple  errors  should  be  considered  under  the  current 
system.  This  contention  is  based  on  the  results  of  applying  the 
DODSSR  validation  criteria  to  the  DODSSR  data  base.  In  Chapter 
I  of  this  Volume  the  number  of  rejects  per  reject  chain  pattern 
was  discussed  and  illustrated  by  Figure  1-94.  These  reject  chains 
were  established  based  on  SSR  transactions  actually  rejected  by 
IMMs.  Figure  1-94  showed  that  for  this  Transition  Period  Popula¬ 
tion  92.0%  of  the  reject  chains  were  rejected  once  and  99.3%  of 
the  reject  chains  contained  either  one  or  two  reject  transactions. 
The  rejected  transactions  in  these  reject  chains  may  have  con¬ 
tained  more  than  the  one  or  two  errors  identified  and  the  DODSSR 
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validation  tends  to  confirm  this.  The  results  of  passing  this 
same  population  thru  the  DoDSSR  Validation  Criteria  is  shown  in 
Figure  III-17. 

DISTRIBUTION  OF  NUMBER  OF  ERRORS  PER  RECORD 
(Type  Transaction  Column  Percent) 
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Figure  III-17 

This  figure  shows  that  the  99*  level  is  not  reached  until  up  to 
five  errors  per  record  are  encountered.  Although  the  reject 
chains  were  not  limited  to  Invalid  data  rejects  alone,  the  amount 
of  manual  corrections  and  editing  being  performed  by  SICCs  and 
IMMs  is  indicated.  A  choice  must  be  made  as  to  whether  the  IMMs 
may  continue  to  correct  invalid  transactions  or  whether  a  stan¬ 
dardized  edit/validation  criteria  will  be  used  to  reduce  the 
number  of  errors  per  record.  To  the  extent  that  improved  edit/ 
validation  criteria  can  be  developed  and  implemented  by  SICCs 
and  IMMs,  the  requirement  for  a  multiple  error  procedure  is 
reduced . 

5 .  Validation  Reject  Trend  Analysis 

The  IMM  Manual  which  was  implemented  on  1  May  1978  con¬ 
tains  formats  and  procedures  which  were  different  from  those 
previously  used.  To  determine  the  effects  of  learning  these  new 
formats  and  procedures  the  data  base  was  stratified  into  two  four 
month  segments.  The  first  segment  is  designated  the  Transition 
Period  and  runs  from  1  May  thru  31  August  1978.  The  second  seg¬ 
ment  is  designated  the  Steady  State  Period  and  covers  the  remain¬ 
der  of  the  data  collection.  These  two  subpopulations  were  then 
validated  to  determine  if  any  significant  changes  occurred  be¬ 
tween  the  two  timeframes.  In  terms  of  the  previous  discussions 
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relating  to  data  elements  causing  errors  and  multiple  errors, 
the  two  subpopulations  indicate  results  similar  to  the  total 
data  base  as  described  above.  However,  there  are  certain  dif¬ 
ferences  between  these  subpopulations  which  are  important* 

The  combinations  of  validation  hierarchical  errors  are 
shown  by  Service  for  the  two  subpopulations  in  Figure  III-18. 

This  figure  illustrates  that  there  is  a  definite  shift  from 
detail  only  and  hierarchy  combination  errors  in  the  Transition 
Period,  to  single  package  errors  in  the  Steady  State  Period  in 
the  Army,  Navy,  and  Air  Force.  In  the  Army,  this  shift  is  to 
both  PCC  package  errors  and  LISSR  package  errors  while  for  the 
Navy  and  Air  Force  the  shift  is  almost  totally  to  PCC  package 
errors.  Note  the  percentage  shift  of  about  322  less  for  detail 
only  errors  to  about  332  more  for  PCC  package  errors  between  the 
two  periods  in  the  Air  Force.  The  Marine  Corps  shows  a  totally 
different  pattern  than  the  other  Services.  The  Marine  Corps 
appears  to  decrease  error  percentage  in  the  PCC  package  and 
detail  error  combination  and  the  PCC  package,  LISSR  package  and 
detail  combination  with  an  almost  equivalent  increase  in  detail 
only  errors.  This  indicates  that  while  the  Army,  Navy,  and  Air 
Force  improved  in  making  proper  data  element  entries,  they  were 
having  problems  getting  transactions  in  the  proper  package  for¬ 
mats.  The  Marine  Corps,  on  the  other  hand.  Improved  in  getting 
transactions  with  errors  in  multiple  levels  down  to  transactions 
with  errors  in  a  single  level  and  improvement  was  primarily  in 
the  package  area.  Figure  III-18  shows  more  generally  that  the 
shift  is  from  multiple  combination  errors  to  a  single  hierarchical 
error . 

Figure  III-19  shows  the  distribution  of  number  of  errors 
per  record  by  DIC  for  both  the  Transition  Period  and  the  Steady 
State  Period.  This  figure  illustrates  the  fact  that  as  the 
Services  became  more  familiar  with  the  IMM  Manual  the  number  of 
errors  per  record  was  significantly  reduced. 

The  trends  illustrated  by  these  figures  show  that  errors 
in  multiple  levels  are  decreasing  and  the  number  of  errors  per 
record  are  decreasing  as  the  Components  gain  familiarity  with 
the  IMM  Manual  and  the  procedures  contained  therein.  Although 
the  number  of  errors  per  record  are  decreasing,  a  significant 
percentage  of  records  (over  302  in  most  cases)  contain  two  or 
more  errors  even  in  the  Steady  State  Population.  This  indicates 
that  although  the  requirement  for  multiple  error  identification 
still  exists;  the  number  of  errors  that  need  be  Identified  may 
be  less  than  the  number  indicated  for  the  DODSSR  data  base  as  a 
whole . 
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ACTION  TAKEN  CODE  USAGE 


The  IMM  Manual  provides  for  specific  Action  Taken  Codes 
(ATCs)  to  be  used  by  IMMs  to  relate  accept/of f er /re ject/NSN 
Notification  advice  to  SICCs.  In  Chapter  I  of  this  Volume,  the 
DODSSR  Study  Team  categorizations  of  these  ATCs  and  the  relative 
occurrence  of  each  category  was  discussed.  The  reject  ATCs  were 
divided  into  seven  subcategories  of  which  invalid  data  was  one 
subcategory.  This  one  subcategory  contains  27%  of  the  ATCs  in 
the  IMM  Manual  and  are  the  ones  resulting  from  automated  or  man¬ 
ual  validations.  DLA  in  its  automated  systems  design  has  used 
these  ATCs  exclusively;  however,  the  Army,  Navy,  Air  Force,  and 
GSA  have  developed  Component  unique  ATCs  as  part  of  their  systems 
design.  While  the  Navy,  Air  Force,  and  GSA  unique  ATCs  bear  no 
resemblance  in  meaning  to  those  contained  in  the  IMM  Manual,  the 
Army  includes  those  from  the  IMM  Manual  as  part  of  the  Army  uni¬ 
que  ATCs.  Although  these  Component  unique  ATCs  are  generally  to 
be  used  within  the  Component  only,  some  of  these  codes  may  be 
disseminated  in  advice  transactions  to  other  Component  activi¬ 
ties  particularly  by  the  Army.  This  usage  of  Component  unique 
ATCs  on  an  intra-activity/Component  basis  and  IMM  Manual  ATCs  on 
an  inter-ac ti vit y/ Component  basis  is  likely  to  cause  confusion 
in  the  automated  systems  and  in  manual  interpretation  by  func¬ 
tional  users. 

The  unique  ATCs  used  by  each  of  the  Services  as  well  as  those 
from  the  IMM  Manual  are  listed  in  Appendix  D.  A  review  of  these 
unique  ATCs  indicates  that  they  generally  fall  in  the  invalid 
data  category  of  ATCs.  Figure  III-20  shows  the  ATCs  used  by  each 
of  the  Services,  DLA  and  the  DODSSR  validation  criteria  for  each 
of  the  data  elements  contained  in  a  PDSSR  transaction.  Note  that 
the  IMM  Manual  provides  for  a  single  ATC  (52)  to  be  used  when  a 
validation  error  in  any  mandatory  data  element  in  a  PDSSR  trans¬ 
action  is  encountered,  and  that  ATC  36  (other)  must  be  used  when 
an  error  is  found  in  Date  NSNs  are  Required  or  Weapons  System 
Code.  Figure  III-20  clearly  shows  that  the  internally  used. 
Service  unique  ATCs  are  designed  to  identify  the  specific  data 
element  in  error.  Although  the  GSA  unique  ATCs  are  not  shown, 
they  are  designed  to  perform  this  same  function.  Note  that  each 
data  element  not  automatically  assigned  or  bypassed  is  assigned 
a  separate  ATC  by  each  Service.  If  similar  figures  were  to  be 
developed  for  USSR  data  elements,  catalog  transaction  data  ele¬ 
ments  and  LIAC  data  elements,  they  would  similarly  indicate  that 
specific  ATCs  were  developed  for  each  data  element  rather  than 
using  the  more  generalized  ones  in  the  IMM  Manual;  i.e.,  '32' 

and  '36.'  This  is  exemplified  by  Figure  III-21  which  shows  the 
ATCs  used  by  each  Component  for  the  control  data  elements  in 
LISSR  transactions.  The  IMM  Manual  ATC  applicable  to  an  error 
in  any  of  these  control  data  elements  is  '32.' 
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Validation  Specification. 

Figure  III-21 

The  more  specific  internal  ATCs  generated  and  used  by  the 
Components  show  that  the  reject  ATCs  for  invalid  data  in  the 
IMM  Manual  are  not  sufficient  in  identifying  error  conditions. 

As  shown  in  Figures  III-20  and  III-21  the  DODSSR  validation  cri¬ 
teria  broke  down  the  IMM  Manual  generalized  ATCs  into  one  data 
element,  one  ATC  combination.  The  Component  unique  validation 
reject  ATCs  are  listed  in  Appendix  D. 

F .  SUMMARY  ANALYSIS  AND  CONCLUSIONS 

This  Chapter  presented  the  validation  conventions  and  cri¬ 
teria  used  by  the  Components  to  validate  and  edit  incoming  and 
outgoing  SSR  transactions.  The  major  concepts  presented  In¬ 
cluded  specific  hierarchies  of  validation,  multiple  validation 
concepts,  and  reject  code  usage  concepts.  These  concepts  and 
the  specific  validation  criteria  were  combined  into  a  DODSSR 
validation  criteria  which  was  applied  to  the  DODSSR  data  base  to 
determine  the  major  causes  of  errors  in  SSR  transactions. 

The  hierarchies  and  validation  levels  used  by  each  of  the 
Components  and  in  the  DODSSR  validation  criteria  is  seen  to  be  a 
direct  result  of  the  package  requirement  stipulated  -  sometimes 
indirectly  -  by  the  IMM  Manual.  It  is  significant  that  this  same 
package  requirement  is  the  major  source  of  errors  in  the  DODSSR 
data  base  and  that  the  only  error  encountered  in  almost  57Z  of 
the  LISSR  transactions  found  to  be  invalid  was  a  PCC  package 
error.  As  was  discussed  in  Volume  II  this  package  concept  is 
used  by  each  of  the  Services  in  provisioning  equipment,  but  is 
not  necessarily  used  in  their  manual  or  automated  SSR  processing. 
As  evidenced  in  this  same  Volume,  SSR  processing  on  an  IMM  basis 
subsequent  to  validation  is  strictly  on  an  item  basis  not  a 


package  basis.  Therefore,  the  usage  of  the  specific  data  ele¬ 
ments  within  PDSSR  and  other  SSR  transactions  must  be  closely 
examined  to  determine  if  it  is  possible  to  reduce  the  impact  of 
this  package  concept  and  more  importantly  reduce  the  errors 
attributable  to  this  concept  in  SSR  processing. 

Duplicate  validation  is  also  a  product  of  validation  conven¬ 
tions  and  contributed  significantly  to  the  error  volumes  in  the 
DODSSR  data  base.  Although  much  of  this  duplicate  error  volume 
is  due  to  the  eight-month  cycle  of  data  collection,  one  point  is 
apparant.  Duplicate  validation  is  required  to  prevent  different 
items  of  supply  from  being  submitted  with  identical  control  ele¬ 
ments.  The  DODSSR  data  base  contains  some  of  these  duplicate 
transactions  as  discussed  in  Chapter  I  of  this  Volume.  Many  of 
these  duplicate  transactions  would  not  be  evidenced  under  Compo¬ 
nent  validation  criteria  because  duplicate  transaction  valida¬ 
tion  is  generally  performed  only  on  transactions  input  to  the 
current  automated  cycle.  To  determine  many  of  the  duplicate 
transactions  found  in  the  data  base  a  duplicate  check  would  have 
to  be  made  against  the  Component  SSR  Suspense  File. 

Detail  data  element  validation  of  the  DODSSR  data  base  indi¬ 
cates  that  the  majority  of  the  data  element  errors  that  occur 
are  in  Other  Mandatory  data  elements.  This  is  true  for  all  four 
types  of  SSR  transactions  including  PDSSR  transactions,  LISSR 
transactions,  catalog  transactions  and  LIAC  transactions.  The 
data  elements  contained  in  this  validation  level  require  review 
as  to  their  actual  usage  to  determine  if  they  can  be  eliminated 
or  edited  to  reduce  the  volume  of  invalid  data  errors  they  are 
causing.  A  single  key  data  element  was  found  to  be  causing  a 
significant  number  of  errors  in  CXA/CXC  transactions.  The  PMC 
is  used  in  conjunction  with  the  Unit  Price  to  distinguish  be¬ 
tween  an  Active  NSN  LISSR  transaction  and  an  Inactive  NSN  LISSR 
transaction  by  DLA  and  in  the  DODSSR  validation  criteria.  As  a 
result  the  validation  of  these  two  data  elements  is  tied  together, 
so  that  when  Unit  Price  is  blank,  the  PMC  should  be  blank  and 
when  the  Unit  Price  is  numeric,  the  PMC  must  contain  a  valid 
code.  When  these  conditions  are  not  met  the  LISSR  transaction 
is  rejected  based  on  a  PMC  error.  When  the  LISSR  transaction  is 
for  an  active  NSN  neither  of  these  data  elements  are  required  in 
the  LISSR  transaction  or  needed  for  processing  and  therefore 
need  not  be  validated.  In  addition,  at  least  one  Component  was 
routinely  placing  the  Unit  Price  in  most  LISSR  transactions,  but 
not  the  PMC.  Obviously,  this  situation  causes  needless  rejec¬ 
tion  of  LISSR  transactions.  If  LISSR  transactions  for  active 
NSNs  need  to  be  distinguished  from  those  for  inactive  NSNs ,  the 
IMM  Manual  should  provide  a  better  method  of  doing  this;  such  as, 
separate  DICs. 


A  final  product  of  this  validation  hierarchy  is  the  concept 
of  not  validating  LIAC  transactions.  The  validation  of  the 
DODSSR  data  base  clearly  illustrates  that  LIAC  transactions  do 
require  validation  prior  to  submission  and  upon  receipt.  The 
nonvalidation  of  LIAC  transactions  is  potentially  due  to  the 
lack  of  a  procedure  or  method  of  relating  LIAC  transactions  in 
error  (except  offer  reply  transactions)  to  the  LIAC  submitter. 

The  Navy  and  Air  Force  have  included  multiple  validation  re¬ 
ject  concepts  into  their  respective  automated  SSR  Applications. 
The  validation  of  the  DODSSR  data  base  as  a  whole  provides  sup¬ 
port  for  this  multiple  validation  reject  concept  under  the  cur¬ 
rent  IMM  Manual  procedures  and  formats.  However,  to  the  extent 
that  specific  data  elements  producing  the  volume  of  single  and 
multiple  errors  continue  to  be  manually  corrected  or  extensively 
edited  when  invalid  by  IMMs,  and  to  the  extent  that  the  trend 
continues  to  move  from  multiple  level,  multiple  errors  to  single 
level,  single  errors  the  requirement  for  multiple  error  identifi¬ 
cation  to  SICCs  by  IMMs  is  reduced.  Multiple  validation  of  SSR 
transactions  from  a  SICC  basis  prior  to  submission  is  definitely 
a  concept  which  should  be  considered  by  all  SICC  Services  in  the 
design/redesign  of  their  respective  automated  SSR  Applications; 
however,  this  concept  must  also  be  evaluated  in  terms  of  editing, 
corrections,  and  multiple  error  trends. 

The  automated  SSR  Application  design  of  the  Army,  Navy,  Air 
Force  and  GSA  provide  for  internal  use  of  reject  codes  peculiar 
to  each  Component.  These  internal  reject  codes  tend  to  identify 
specific  data  elements  in  error  not  currently  covered  by  specif¬ 
ic  reject  codes  within  the  IMM  Manual.  Adherance  to  the  IMM 
Manual  would  require  these  Components  to  use  the  more  general¬ 
ized  rejects  codes  (52,  32,  36).  This  is  a  direct  indication 
that  the  current  reject  codes  are  not  sufficient  and  that  they 
need  to  be  expanded  to  a  "one  reject  code  -  one  data  element" 
basis  or  that  some  other  means  of  identifying  specific  data  ele¬ 
ments  in  error  should  be  provided. 

Finally,  the  comparison  of  the  validation  criteria  used  by 
the  Components  shows  that  generally  this  criteria  is  not  con¬ 
sistent  from  Component  to  Component  for  all  data  elements.  For 
a  few  data  elements  the  criteria  is  identical  for  all  Components, 
but  the  vast  majority  of  data  element  are  not  validated  on  a 
consistent  basis.  This  fact  alone  causes  error  conditions  to 
occur.  In  addition,  there  is  some  variation  within  the  Services 
on  the  same  data  element  when  validated  as  a  SICC  vs.  validation 
as  an  IMM.  This  is  particular  true  in  the  Air  Force  where  a 
very  structured  validation  is  performed  for  outgoing  SICC  SSR 
transactions  and  minimal  automated  validation  is  performed  on 
Incoming  WIMM  SSR  transactions.  The  philosophy  behind  this  wide 
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variation  in  validation  criteria  clearly  explains  this  differ¬ 
ence*  The  outgoing  transactions  are  subjected  to  the  strict 
validation  in  an  effort  to  allow  these  transactions  to  pass  IMM 
validation  vhile  only  data  elements  required  to  process  the  SSR 
transactions  in  the  automated  SSR  Application  are  validated  in 
Incoming  SSR  transactions*  Other  data  elements  are  validated  by 
functional  personnel  as  described  in  the  section  on  manual  vali¬ 
dation  criteria.  This  indicates  that  there  are  some  data  ele¬ 
ments  which  may  have  little  or  marginal  utility  and  may  be  edited 
or  bypassed  in  validation.  One  good  example  of  this  is  a  key 
data  element  which  is  apparantly  used  only  by  DLA  and  is  used  in 
conjunction  with  Unit  Price  to  distinquish  a  Condition  1  NSN  SSR 
submittal  from  a  Condition  2  NSN  SSR  submittal.  This  key  data 
element  is  the  Procurement  Method  Code  which  appeared  as  the 
rlmary  contributor  to  key  data  element  validation  level  errors 
ithin  the  DODSSR  Data  Base.  The  relative  use  of  specific  data 
elements  is  discussed  further  in  Chapter  V,  Volume  I,  to  deter¬ 
mine  specific  data  elements  which  may  be  eliminated,  edited  or 
bypassed  to  permit  processing  of  the  SSR  transaction;  not  rejec¬ 
tion  of  the  SSR  transaction. 
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APPENDIX  A 


QUANTITATIVE  EVALUATION  PLAN 


I .  PURPOSE 

To  apply  quantitative  methods  to  the  evaluation  of  the  Supply 
Support  Request  (SSR)  systems  and  procedures  in  order  to  determine 
the  relative  ef f ic iency/ef f ec t i veness  of  Service /Agency  systems 
and  procedures  that  were  developed  to  implement  DoD  4140. 26M, 
Volume  1,  May  1978. 

II  .  PROBLEM  OBJECTIVE 

To  measure  the  performance  of  the  respective  SSR  systems,  in 
support  of  the  study  objectives  as  stated  in  the  Study  Plan. 

III .  BACKGROUND 

It  has  been  alleged  that  SSRs  are  not  being  processed  in  a 
timely  manner  which  is  necessary  to  ensure  effective  and  effi¬ 
cient  supply  support  of  end  items  of  materiel.  Examples  of 
problems  reported  include  extended  transmission  times,  a  high 
rate  of  rejects,  and  the  lack  of  a  management  control  system  to 
monitor  and  control  the  overall  SSR  process. 

IV.  APPROACH 
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V.  CONSTRAINTS 

Time  limitation  of  study  constrains  data  collection  to  an 
8-month  timeframe. 

VI .  METHODOLOGY 

A.  Identify  the  major  submitters  and  receivers  of  SSRs. 

B.  Develop  a  data  collection  system. 
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C.  Collect  actual  transaction  data  from  each  SSR  submitter 
and  receiver  for  a  specified  period  of  time. 

D.  Establish  a  data  base  to  permit  computerized  processing 
of  the  data. 

E.  Purify  the  data  base. 

F.  Develop  evaluation  criteria  to  be  used  in  the  analysis 
of  the  collected  data. 

1.  Goals 

2.  Standards 

3.  Times 

4.  Other  measures  of  effectiveness/efficiency 

G.  Develop  analytical  models  of  the  SSR  systems,  manual  and 
computer  requirements  specifications  and  programs  for  descriptive 
and  analytical  reports  to  evaluate  these  systems. 

H.  Stratify  data  population  and  process  data  through  the 
models  and  reports  programs. 

VII.  EVALUATION 

Analyze  computer  and  manually  generated  statistics  to  deter¬ 
mine  relative  system  performance.  Compare  actual  performance 
with  evaluation  factors,  goals  and  standards  and  recommend  system 
Improvements  as  applicable. 
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APPENDIX  B 

DEFENSE  SUPPLY  AGENCY 

DEFENSE  LOGISTICS  ANALYSIS  OFFICE 
CAMERON  STATION 
ALEXANDRIA,  VIRGINIA  22314 

21  March  1978 

SUBJECT:  Department  of  Defense  Supply  Support  Request  (DODSSR)  Study 
Data  Collection 


TO:  Deputy  Chief  of  Staff  for  Logistics,  U.S.  Army  (DALO-SML) 

Commander,  Naval  Supply  Systems  Command,  (Code  0342C) 

Deputy  Chief  of  Staff,  Systems  &  Logistics,  U.S.  Air  Force  (AF/LGYPS) 
Commandant  of  the  Marine  Corps  (Code  LMO-2) 

Director,  Defense  Logistics  Agency  (DLA-OPL) 

1.  By  Memorandum  dated  August  17,  1977,  the  Deputy  Assistant  Secretary  of 
Defense  (Supply,  Maintenance  &  Services)  established  a  Department  of  Defense 
Study  Group  to  conduct  a  comprehensive  review  and  analysis  of  the  supply 
support  request  (SSR)  processing  and  interfacing  systems  for  generating, 
transmitting,  processing  and  controlling  SSRs  in  order  to  develop  systems 
improvements  to  promote  effective  and  efficient  supply  support  of  DoD  equip* 
ment. 


2.  To  accomplish  this  study  objective  in  accordance  with  the  study 
requirement,  it  is  necessary  to  collect  data  to  permit  an  objective  analysis 

of  systems,  procedures,  formats  and  conventions.  Data  collection  requirements, 
including  designated  submitting  activities,  time  frames,  and  procedures  are 
outlined  in  the  enclosures  to  this  letter. 

3.  In  order  to  facilitate  complete  understanding  of  the  data  collection,  it 

is  requested  that  a  contact  point  be  designated  at  each  Service/Agency/Activity 
submitting  data  and  that  the  contact’s  name,  address  and  telephone  number  be 
provided  to  the  DODSSR  Study  Team  below: 

Defense  Logistics  Analysis  Office 
DODSSR  Study 
Cameron  Station 
Alexandria,  VA  22314 

AUTOVON  284-6283 
Commercial  202-274-6283 

4.  This  requirement  is  assigned  Reports  Control  Symbol  DD-M(OT)7811. 


3  Enel 

1.  Data  Collection  Requirements 

2.  AUTODIN  Control  Cards  Requirements 

3.  List  of  Submitting  Activities 


T.D.  BECK 
Director 
DODSSR  Study 
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DODSSR  DATA  COLLECTION  REQUIREMENTS 

I.  REFERENCES: 

A.  DoD  4140. 26M,  Vol  I,  Subject:  Defense  Integrated  Materiel 
Management  for  Consumable  Items. 

B.  Joint  Regulation:  AFLC  Regulation  400-21 

DARCOM  Regulation  700-99 
NAVMATINST  4790.23 
MCO  P4410.22 

Subject:  Elimination  of  Duplication  in  the  Management  and  Logis¬ 

tics  Support  of  Multi-Used  Nonconsumable  Items. 

II.  TYPES  OF  DATA.  Submit  the  following  types  of  data. 

A.  CIMM/WIMM  Consumable  SSR  Transactions.  Reference  IA, 

Ch  4,  and  Appendix  E. 

1.  PDSSR .  (Program  Data  Supply  Support  Request  Cards) 
Document  Identifier  Codes  W/CWA. 

2.  (Line  Item  Supply  Support  Request  Cards)  DIC  W/CX . 

3.  LIAC .  (Line  Item  Advice/Followup  Cards)  DIC  CX . 

B.  NIMSR .  Nonconsumable  Item  Materiel  Support  Requests, 
Reference  IB,  Appendix  D. 

III.  PROCEDURES 


A.  Scope .  Submit  copies  of  all  C IMM/WIMM/NIMSR  transactions 
generated,  submitted,  or  received  either  intra-  or  inter-Service/ 
Agency  during  the  period  1  May  1978  through  31  October  1978. 

B .  Duplication 

1.  CIMM/WIMM  Consumable.  Reproduce/duplicate  the  trans¬ 
actions  entering  the  date  (Julian  date,  i.e.,  8121  for  May  1, 
1978)  actually  submitted  or  received  in  character  positions  60-63 
of  each  and  every  PDSSR/LI SSR/LI AC  transactions. 

2.  NIMSR .  Annotate  the  Julian  date  actually  submitted 
or  received  on  each  and  every  NIMSR  Request/Advice  Followup  form/ 
letter/memo  submitted  or  received. 
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C.  Data  Submission 


1.  CIMM/WIMM  Consumables.  Submit  data  via  AUTODIN  using 
the  AUTODIN  Control  Cards  and  to  the  address  listed  in  Enclosure  2. 

2.  NIMSR «  Submit  via  mail  to  the  following  address: 

Defense  Logistics  Analysis  Office 
ATTN:  DODSSR  Study  Group 

Cameron  Station 
Alexandria,  VA  22314 

IV.  SCHEDULE  OF  SUBMISSIONS.  1  May  to  31  October  1978. 

A.  CIMM/WIMM  Consumables.  May  be  submitted  on  a  dally  basis 
via  AUTODIN  or  batched  and  sent  based  upon  local  data  processing 
cycle  of  dally/weekly/monthly. 

B.  NIMSR.  Mail  on  a  weekly  or  monthly  basis,  whichever  is 
more  convenient. 

V.  SUBMITTING  ACTIVITIES.  See  Enclosure  3. 

VI.  CLARIFICATIONS  OF  DATA  REQUIREMENTS 

A.  Data  Processing/Communications  Conventions: 

Mr.  Paul  Leonard 
AUTOVON  284-7212 
Commercial  202-274-7212 

B.  Other  Clarifications: 

Mr.  P.M.  Daniels 
AUTOVON  284-6283 
Commercial  202-274-6283 
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AUTODIN  CONTROL  CARDS 


Provide  the  following  information  to  identify  and  control  the 
data  collection  submissions  forwarded  by  AUTODIN. 


TEXT  HEADER  CARD 

S SR  Data  RCS  _ 

Paul  W.  Leonard 
DASC-D 

Content  Indicator  DHAE 


TEXT  BATCH  CARD 

Batch  _  of  _ .  (Indicate  individual 

batch  number  and  total  number  of  batches.) 


AUTODIN  HEADER  CARD 

Provide  Data  Message  Form  DD  1392  using  Content  Indicator 
DHAE  and  Language  Media  Format  (LMF)  Code  C£  as  shown  in  pages  2 
and  3  of  this  Enclosure  2.  Communications  Routing  Identifier 
RUEBDSA  applies  and  will  be  assigned  by  the  communications  center 
or  data  processing  when  preparing  message  header  format  using 
the  data  in  the  DD  Form  1392. 
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PREPARATION  OF  THE  DATA  MESSAGE  FORM 


General .  DD  Form  1392  Is  designed  to  provide  the  communica¬ 
tions  center  with  information  to  prepare  header  cards  for  trans¬ 
mission.  Data  message  originators  who  do  not  prepare  the  header 
format  for  transmission  will  deliver  the  message  text  to  the 
communications  center  with  a  completed  DD  Form  1392.  Addressees 
and  their  geographical  location  must  be  entered  on  this  form  in 
clear  text.  Coded  addressees  and  APO/FPO  numbers  will  not  be 
used.  Data  message  are  limited  to  a  maximum  of  300  cards  includ¬ 
ing  the  header  and  end-of-transmission  (EOT)  cards.  Messages  of 
greater  length  will  be  transmitted  as  two  or  more  transmission 
sections.  These  instructions  are  for  data  message  originators 
who  do  not  prepare  the  header  format. 

Precedence .  Enter  ROUTINE. 

Language  Media  Format  (LMF).  Enter  CC . 

Classification.  Enter  UNCLASSIFIED. 

Addressee:  Forward  to  the  following  address: 

DEFENSE  LOGISTIC  AGENCY 
CAMERON  STATION 
ALEXANDRIA,  VA  22314 

Card  Count .  Enter  the  total  number  of  cards  being  sent  to 
the  communications  center.  An  accurate  count  of  cards  is  essen¬ 
tial.  The  count  may  not  exceed  498  cards  for  one  message  when 
the  header  and  EOT  card  will  be  prepared  by  communications  center 
personnel . 

Originator's  Identification.  This  block  serves  the  same  pur¬ 
pose  as  the  FROM  line  on  the  DD  Form  173.  Enter  the  title  of  the 
originating  activity. 

Content  Indicator.  Enter  DHAE. 

Releasing  Officer's  Signature.  Type  name  and  title  of  re¬ 
leaser  in  upper  part  of  block.  Releaser  must  sign  this  block 
before  the  message  is  delivered  to  the  communications  center. 

Office  Symbol  and  Extension.  Enter  office  symbol  and  tele¬ 
phone  extension  of  the  drafter. 

Remarks .  This  block  may  be  used  for  local  special  handling 
instructions,  and  to  insert  the  phrase  "MINIMIZE  considered” 
during  periods  when  MINIMIZE  has  been  imposed. 
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SAMPLE 


DATA 

MESSAGE  FORM 

PRECEDENCE 

ROUTINE 

Ilmf 

1 

I  cc 

_ _ _ 1 _ 

CLASSIFICATION 

UNCLASSIFIED 

AOORESSEE/CIfar  Text) 

DEFUSE  LOGISTICS  AGENCY,  CAMERSON  STATION,  ALEXANDRIA 

CARO  COUNT 
(Del at!  eardt) 

k,  VA.  22314 

ORIGIN  AT  Off'S  IDENTIFICATION 
folio*  up.  HOlUi,  fU.) 

<KCS. 

CONTENT  INO  RELEASING  OFFICERS 

SIGNATURE  OFFICE  SYMBOL  * 

EXT. 

REMARKS 

FOR  COM  Ml  SWAT  U>SS  CENTER  l  St  ONLY 

ORIGINATOR  S  ROUTING  INDICATOR 

STATION  SERIAL  NUMBER 

DATE-TIME  (Tune  filed) 

TOTAL  CARD  COUNT 

ADDRESSEE  ROUTING  INDICATOR 

SUPERVISORS  SIGNATURE 

OPERATOR  S  SIGNATURE 

TIME  TRANSMITTED 

CLASSIFICATION 

\ 
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DO  FORM  1392  .  1  AUG  62 


SUBMITTING  ACTIVITIES 


ARMY 


ARRCOM 

CERCOM 

MIRCOM 

TARCOM 

TSARCOM 

NAVY 


ASO 

SPCC 

AIR  FORCE 


OCALC 

OOALC 

SAALC 

SMALC 

WRALC 

MARINE  CORPS 


MCLSBA 

DEFENSE  LOGISTICS  AGENCY 


DCSC 

DESC 

DGSC 

DISC 


Enel  3 
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APPENDIX  C 


OFFICE  OF  THE  SECRETARY  OF  DEFENSE 

WASHINGTON,  D.  C.  20301 


DEFENSE  LOGISTICS  16  June  1978 

ANALYSIS  OFFICE 

SUBJECT:  Department  of  Defense  Supply  Support  Request 

(DODSSR)  Study  AUTODIN  Test 


TO  :  DODSSR  Study  AUTODIN  Test  Contact  Points 


1.  The  development  and  conduct  of  an  AUTODIN  Test  by  the 
DODSSR  Study  Group  was  discussed  and  approved  in  principle 
at  the  Special  Projects  Group  for  Provisioning  meeting  of 

29  March  1978.  Specific  procedures  and  participating  members 
were  to  be  negotiated  and  arranged  by  the  Study  Group  with 
Services/ Agencies. 

2.  The  purpose  of  the  test  is  to  determine  the  feasibility 
of  transmitting  and  receiving  Supply  Support  Requests  (SSRs) 
over  AUTODIN.  A  draft  test  plan  has  been  developed  by  the 
Study  Group  for  consideration.  This  plan  outlines  proposed 
Test  objectives,  procedures,  participating  activities  and 
schedule • 

3.  In  order  to  proceed  with  this  test  within  the  confines  of 
the  study  schedule,  it  is  requested  that  the  Service/Agency 
AUTODIN  Contact  Points  meet  with  the  DODSSR  Study  Group  to 

d 1 8 cus s  the  enclosed  Test  Plan  and  participate  in  development 
of  test  plans  and  procedures. 

4.  The  meeting  will  be  convened  at  the  Dwyer  Building,  3220 
Duke  Street,  Alexandria,  Virginia  at  0800  on  Friday,  June  23, 
1978.  Major  G.T.  Amos ca to  may  be  contacted  on  AUTODIN  284- 
6283  or  AC  202-274-6283  regarding  visit  arrangements. 


T.D.  BECK 
Director , 
DODSSR  Study 


cc:  (w/o  end) 

0ASD  (MRA&L)  SR 
DCSLOG  ( DAL0-SML) 

AF/LGYPS 
HQ  MC  (LM0-2) 
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DODSSR  STUDY 


AUTODIN/TELEFAX  TEST  PLAN 


I.  PURPOSE 

This  test  is  being  conducted  to  determine  the  feasibility  of 
transmitting  and  receiving  Supply  Support  Requests  over  AUTODIN. 

II.  REFERENCES 

A.  ASD  (MRA&L)  SM&S  memo  of  August  17,  1977,  Subject: 
Establishment  of  Supply  Support  Request  (SSR)  Study. 

B.  Special  Projects  Group  for  Provisioning  (SPG)  Meeting  of 
29  March  1978. 


C.  Special  Projects  Group  for  Provisioning  (SPG) 
18  July  1978. 


Meeting  of 


D.  DLAO  letter  of  23  June  1978,  Subject:  DODSSR  Study 
AUTODIN  Test. 

E.  DLAO  letter  of  25  July  1978,  Subject:  DODSSR  Study 
AUTODIN  Test. 

F.  DLAO  letter  of  24  August  1978,  Subject:  DODSSR  Study 
AUTODIN  Test. 

G.  DLAO  letter  of  12  October  1978,  Subject:  DODSSR  Study 
AUTODIN  Test. 

H.  DLAO  letter  of  22  November  1978,  Subject:  DODSSR  Study 
AUTODIN  Test. 


I.  DoD  4140. 26M,  Vol  I,  Subject:  Defense  Integrated 
Materiel  Management  for  consumable  Items. 

J.  DLAO  letter  of  21  March  1978,  Subject:  DODSSR  Study 
Data  Collection. 


K •  DLAO  letter  of  24  August  1978,  Subject:  DODSSR  Study 
Data  Collection. 

L.  MIL-STD-1561  of  11  Nov  1974,  Subject:  Provisioning 
Procedures,  Uniform  DoD. 
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BACKGROUND 


The  DODSSR  Study  was  assigned  by  Reference  A  to  review  and 
analyze  the  SSR  processing  and  interrelated  systems  to  identify 
problems  associated  with  the  systems  used  to  generate,  transmit, 
process  and  control  SSRs  and  to  recommend  improvements  to  increase 
the  effectiveness  and  efficiency  of  these  systems. 

During  numerous  meetings  of  the  SPG,  problems  have  been  iden¬ 
tified  that  relate  to  the  transmission  and  control  of  SSRs.  The 
use  of  AUTODIN  for  SSRs  has  been  recommended  as  a  potential  solu¬ 
tion  to  problems  associated  with  the  transmission  of  SSRs,  How¬ 
ever,  there  has  not  been  universal  agreement  on  the  use  of  AUTODIN 
for  this  purpose.  In  order  to  properly  evaluate  AUTODIN  as  an 
alternative,  the  DODSSR  Study  Group  proposed  and  received  approval 
in  principle,  during  Reference  B  meeting  to  conduct  an  AUTODIN 
Test.  An  extension  of  the  test  to  30  November  1978  was  authorized 
during  Reference  C. 

References  D-H,  forwarded  test  plans  for  the  AUTODIN  Test. 

The  test  plans  were  discussed  by  the  study  team  and  participating 
activities.  Subsequent  to  the  development  of  the  initial  plans 
for  the  electrical  transmission  of  SSRs  over  AUTODIN,  the  study 
team  developed  a  plan  for  the  electrical  transmission  of  tech¬ 
nical  data  using  telecommunications  facsimile  (TELEFAX)  equip¬ 
ment.  Implementation  procedures  for  the  electrical  transmission 
of  SSR  and  technical  data  have  also  been  developed  and  are  in¬ 
cluded  in  the  test  plan.  Evaluation  guidelines  were  also  devel¬ 
oped  and  are  Included  as  an  attachment  to  the  test  plan. 

IV.  OBJECTIVES 

A.  Decrease  transmission  times  for  submissions,  followups 
and  replies . 

B.  Improve  control  and  provide  an  audit  trail  from  the  time 
an  SSR  has  been  prepared  by  the  submitting  activity  until  com¬ 
municated  to  and  received  by  the  receiving  activity  and  introduced 
into  processing. 

C.  Decrease  SSR  loss  rate. 

D.  Improve  processing  efficiency  at  submitter /receiver 
( SICC/IMM) . 

E.  Improve  processing  effectiveness  at  submitter /receiver 
(SICC/IMM) . 

F.  Increase  accuracy  of  submissions. 


305 


Appendix  C,  page  3 


V 


SCOPE 


All  SICC/CXMM  consumable  SSR  transactions  transmitted  bet¬ 
ween  the  participating  activities  during  the  test  period  as 
covered  by  Reference  I,  Ch  4,  and  Appendix  E.  This  includes  all 
conditions  and  Document  Identifier  Codes  in  the  SSR  Series*  SICC/ 
WIMM  transactions  are  excluded  (both  provisioning  and  nonprovi¬ 
sioning  actions  manually  or  mechanically  generated  from  any 
organizational  element  at  the  submitter  activities)* 

A.  PDSSR .  (Program  Data  Supply  Support  Request  Cards)  Docu¬ 
ment  Identifier  Code  CWA. 


VI . 


VII. 


B.  LISSR .  (Line  Item  Supply  Support  Request  Cards)  DIC  CX _ . 

C.  LIAC .  (Line  Item  Advice/Followup  Cards)  DIC  CX _ . 

PARTICIPATING  ACTIVITIES 

A.  S ICCs  (Submitters) 


Service/Agency 


SSR  AUTODIN 


Tech  Data  TELEFAX 


Army 

Navy 

Air  Force 


TSARCOM 

SPCC 

SHALC 


B.  CIMM  (Receiver) 
Service/Agency  SSR  AUTODIN 

DLA  DG  SC 

CONTACT  POINTS 


SPCC 

SMALC 


Tech  Data  TELEFAX 


DGSC 


Attachment  A  provides  a  list  of  contact  points  for  par¬ 
ticipants  in  the  AUTODIN  Test.  Direct  contact  will  be  made  with 
the  appropriate  contact  point  to  expedite  resolution  of  any  opera¬ 
tional  problems  that  might  come  up  during  the  conduct  of  the  test. 


VIII.  SCHEDULE 

A.  Test  Period.  The  test  will  be  conducted  for  period  of 
four  months.  This  is  considered  the  minimum  time  required  to 
complete  or  close  out  the  majority  of  transactions.  The  intent  is 
to  permit  experience  with  all  types  of  transactions  and  it  is  not 
expected  that  all  transactions  initiated  during  the  period  will  be 
completed. 
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SSR-AUTODIN 


Tech  Data-TELEFAX 


Start  Date  1  September  1978  1  October  1978 

Stop  Date  30  November  1978  31  December  1978 


B.  Evaluation  Period.  Although  it  is  intended  that  the  test 
will  be  under  constant  assessment  during  the  operational  test,  a 
period  of  one  month  will  be  allotted  to  evaluating  the  results 
of  the  test*  Each  participating  activity  will  be  expected  to 
submit  a  written  evaluation  report  directly  to  the  DODSSR  Study 
Chairman  by  31  January  1979. 

!X.  TEST  PROCEDURES 

A.  Submission 


1.  Commencing  1  September  1978  all  participating  acti¬ 
vities  will  submit  all  SSR  EAM  card-type  traffic  for  consumable 
items  over  AUTODIN  between  Test  SICCs  and  Test  CIMM  activities 
only.  AUTODIN  content  Indicator  Code  IHFZ  will  be  used.  This 
Includes  all  initial,  change,  resubmission,  advice,  reply,  follow¬ 
up,  and  rejection  traffic  for  all  conditions  using  any  of  the 
Document  Identifier  Codes  outlined  in  V.  SCOPE  above.  Traffic 
will  not  flow  between  test  SICCs  or  nontest  activities. 

2.  SICC  submitters  should  forward  SSR  traffic  to  the 
CIMM  immediately  after  generation  and  validation.  The  same 
general  processing  procedures  and  cycles  should  be  used  to  gener¬ 
ate  SSRs  to  be  forwarded  by  AUTODIN  as  used  for  the  conventional 
mode  for  other  SSR  traffic.  However,  it  is  anticipated  that 
after  generation,  traffic  to  the  Test  CIMM  (DGSC)  may  be  routed 
using  several  options  including: 

a.  Card  submission  from  ADP/EAM  Keypunch  Operations 
to  AUTODIN  Operations. 

b.  Tape  submission  from  ADP  Operations  to  AUTODIN 

Operations . 

c.  Direct  wire  interface  between  ADP  and  AUTODIN 

Operations . 

3.  Controls  should  be  established  to  ensure  that  SSRs 
are  routed  to  AUTODIN  Operations  by  the  most  expeditious  method 
possible  and  that  backup  information  is  retained  in  the  event  of 
1 o 8 s  or  misrouting  of  transactions. 

a.  AUTODIN  Operations  should  retain  backup  data  in 
accordance  with  their  normal  procedures. 
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b.  ADP  Operations  should  maintain  emergency  backup 
files  on  card  or  tape  for  the  duration  of  the  test  with  a  dispo¬ 
sition  date  of  30  June  1979. 

4.  Copies  of  SSR  transactions  are  currently  being  sent 
to  the  DODSSR  Study  Team  by  AUTODIN.  These  transactions  should 
continue  to  be  sent  to  the  study  team  as  outlined  in  Data  Collec¬ 
tion  Procedures  in  References  J  and  K. 

5.  Technical  Data 


a*  Technical  data,  as  defined  in  Reference  L,  page 
2,  paragraph  3.23  includes,  but  is  not  limited  to: 

(1)  Drawings 

(2)  Sketches 

(3)  Wiring  Diagrams 

(4)  Photographs 

(5)  Commercial  catalog  pages  or  descriptions 

(6)  Bills  of  material 

(7)  DLA  Form  546  Standard /A1 ternate  Referral 

(8)  Vendors  letters  of  refusal 

(9)  Any  other  literature  providing  descriptive 
information  of  items  when  technical  data  is  required  to  accom¬ 
pany  SSRs . 

b.  SSRs  requiring  technical  or  supporting  documen¬ 
tation  should  also  be  forwarded  over  AUTODIN  immediately  after 
creation.  A  procedure  should  be  established  by  both  SICCs  and 
CIMM8  to  ensure  that  this  documentation  is  forwarded  as  expedi¬ 
tiously  as  possible  as  possible.  This  documentation  should  con¬ 
tain  the  following  Identifying  control  information  marked  on  the 
face  of  the  drawing  to  facilitate  matching  up  with  the  SSR  by 
the  recipient. 

(1)  PCC  , 

(2)  DOR 

(3)  ISN 

(4)  Activity  Code  (From) 
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c.  Technical  data  for  which  SSRa  are  separately 
forwarded  by  AUTODIN,  will  be  mailed  to  DGSC  during  the  period  1 
September  1978  to  30  September  1978  by  all  submitters  and  TSARCOM 
for  the  entire  test.  The  technical  data  will  be  marked  on  the 
face  of  the  material  with  control  data  as  described  above.  The 
covering  letter  will  contain  a  reference  to  the  AUTODIN  Test. 
Listings  of  SSRs  generated  during  the  Test  will  be  used  to  iden¬ 
tify  SSRs  for  which  technical  data  will  be  submitted. 

d.  Technical  data  will  be  forwarded  to  DGSC  via 
electrical  facsimile  transmission  during  the  period  1  October  1978 
to  30  December  1978  by  TELEFAX  submitting  activities. 

(1)  Control  data  will  be  marked  on  the  face  of 

the  drawing. 

(2)  Technical  data  with  dimensions  of  18"  x  24" 
or  less  will  be  electrically  transmitted  and  the  copy  retained 
in  the  PCC  file. 


(3)  Technical  data  on  aperture"'  cards  will  be 
printed  and  the  hardcopy  will  be  electrically  transmitted  and  the 
hardcopy  will  be  retained  in  the  PCC  file. 

(4)  Oversize  technical  data  (wider  than  18") 
will  be  electrically  transmitted  using  a  hardcopy  obtained  from 
the  technical  library,  which  will  provide  a  minimum  of  24  hour 
turn  around  time  for  aperture  card  print  requests.  If  the  drawing 
is  not  in  the  library,  the  drawing  will  be  forwarded  in  18"  wide 
segments . 


(5)  If  technical  data  can  not  be  forwarded 
electrically  due  to  copy  quality,  multiple  page  commercial  books, 
brochures  and  drawings,  the  functional  contact  point  at  DGSC  will 
be  contacted  for  guidance. 

B .  Receipt,  Control  and  Processing 

1.  The  CIMM  Test  Activity  should  establish  procedures 
and  controls  to  ensure  that  SSR  transactions  received  over  AUTODIN 
are  introduced  into  processing  as  expeditiously  and  efficiently  as 
possible. 


a.  Direct  routing  from  AUTODIN  Operations  to  ADP 
Operations  should  be  accomplished  for  all  transactions  (all  DICs). 

b.  Transactions  for  which  technical  data  is  not 
required  or  will  not  be  provided  will  be  processed  through  the 
entire  SSR  processing  system.  This  group  of  SSRs  consist  of: 
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(1)  Condition  1  SSRs. 

(2)  Condition  2  SSRs  with  PSCNs 


cc  7  3. 


(3)  Technical  Data  Justification  Code  (TDJC)  in 


(4)  An  SSR  is  accompanied  by  a  CXF  card. 

(5)  A  Condition  3  SSR  that  does  not  require 
techical  data  when  the  manufacturer's  number  in  the  SSR  is  a 
Government  specification  or  standard  including  type  designator 
which  completely  identifies  the  item. 


c.  Transactions  that  require  the  submittal  of  tech¬ 
nical  data  but  the  data  will  not  be  provided  until  some  future 
date  and  the  SSR  contains  a  Date  Technical  Data  to  be  Supplied 
(DTDS),  cc  69-72,  will  be  processed  and  not  held  in  abeyance. 
CIMM  will  followup  for  technical  data  in  accordance  with  current 
procedures  • 


d.  Transactions  that  require  the  submittal  of  tech¬ 
nical  data  which  is  available  at  the  time  of  submittal  of  SSRs 
will  not  be  submitted  with  a  CXF  card,  DTDS,  or  a  TDJC.  SICCs 
will  forward  technical  data  within  24  hours  of  AUTODIN  transmis¬ 
sion  of  SSRs.  These  transactions  which  require  technical  data 
but  which  have  not  yet  been  received  by  the  CIMM  will  be  pro¬ 
cessed  through  the  following  actions: 

(1)  Edit/Validation. 

(2)  Method  of  Support  (MOS)  Determination/ 
Acquisition  Advice  Code  (AAC)  assignment. 

(3)  Record  transaction  In  SSR  Control/  Suspense 

File. 

(4)  DLSC  Screen/Interrogation. 

(5)  Rejection  of  Invalid  transactions. 

(6)  Remaining  actions  will  be  held  in  abeyance 
pending  receipt  of  technical  data.  The  CIMM  (DLA  Provisioning 
Coordination  Office)  will  remain  a  manual  log  to  provide  a 
suspense  control  on  all  Part  Number  Select/NSN  Request  Cards 
(DIC:YDH)  which  require  match-up  to  technical  data.  A  Provi¬ 
sioning  Item  History  Envelope  (PIHE)  will  be  prepared  as  in  the 
nontesting  environment  for  each  Item  Serial  Number  (ISN).  The 
DIC : YDH  card  will  be  placed  in  the  PIHE  until  technical  data  is 
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received  or  the  SSR  Is  returned  for  nonsubmittal  of  technical 
data.  In  the  event  technical  data  is  received  prior  to  the 
receipt  of  the  DIC:YDH  card  a  PIKE  will  be  prepared  and  the 
technical  data  maintained  until  the  DIC:YDH  is  received.  In  no 
Instance  will  a  DICtYDH  which  requires  submittal  of  technical 
data  be  processed  to  the  Cataloging  Division  without  the  tech¬ 
nical  data. 

(7)  The  CIMM,  by  reviewing  his  suspense  control 
log,  will  notify  the  submitter  seven  days  after  receipt  (F-210 
Provisioning  SSR  List  date)  with  a  Line  Item  Advice  Card,  DIC:CX1, 
ATC  99,  that  technical  data  has  not  been  received  and  the  SSR  will 
be  rejected  if  the  technical  data  is  not  received  in  seven  days  of 
the  date  of  this  notice.  If  technical  data  is  not  received  seven 
days  after  this  notice  the  CIMM  will  reject  the  SSR  lacking  tech¬ 
nical  data  with  an  ATC  44. 


(8)  Technical  data  provided  by  a  submitter  for 
an  SSR  which  has  been  rejected  will  be  held  by  the  CIMM  for  resub¬ 
mittal  of  the  SSR.  The  SSR  being  resubmitted  will  contain  the 
same  provisioning  control  data  (PCC/ISN)  as  the  original  (rejected] 
SSR  with  the  exception  of  the  Date  of  Request  (DOR). 


2.  Procedures  and  controls  should  be  established  to 
ensure  that  supporting  techical  data  is  provided  and  received  by 
the  SICC  and  the  CIMM,  and  matched  with  the  appropriate  SSR  tran¬ 
sactions  . 


a.  Initial  and  revised  SSRs. 


b.  Offers  of  alternate  and  substitute  items. 


X.  EVALUATION 


Evaluation  of  the  effectiveness  and  efficiency  of  the  Test 
will  be  a  joint  effort  among  the  Test  Participating  Activities 
(SICCs/CIMM)  and  the  DODSSR  Study  Team.  Three  types  of  analysis 
will  be  performed. 

A.  Participating  activities  will  provide  an  evaluation  of 
the  effects  of  the  test  on  their  operations  in  comparison  with  the 
Non-AUTODIN  transctions  in  terms  of  the  objectives  stated  in  IV 
above.  Attachments  B  and  C  provide  evaluation  guidelines  to  be 
used  by  the  participating  activities  in  performing  this  evalua¬ 
tion. 

B.  The  DODSSR  Study  will  evaluate  the  accomplishment  of 
objectives  through  analyses  performed  on  transactions  submitted 
in  the  data  collection. 
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C.  The  DODSSR  Study  Teas  will  analyse  and  compare  the 
results  of  the  test  based  upon  a  review  and  comparison  of  par¬ 
ticipating  activity  evaluation  reports,  the  data  collection  and 
operational  review  of  the  SSR  processes  at  participating  activi¬ 
ties  • 

Attachments 
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AUTODIN  TEST  CONTACT  POINTS 


Functional  Coordinator  Joe  Stadterman 

Code  562 
Bldg.  312 
Bay  D27 


AUTODIN  TEST  EVALUATION  GUIDELINES 
(SSR  SUBMITTERS) 


I.  For  all  aubalttera: 

Please  rank  and  evaluate  the  following  alternatives  (*)  as 
applicable  to  your  activity,  for  each  area  (A-F)  identified  below. 
Specify  by  SSR  condition,  l.e..  Condition  1,  2,  or  3,  where  possible 

*  SSR  mailed,  technical  data  mailed,  AUTODIN  reply  (DIC  CX1-CX4) 

*  SSR  mailed,  technical  data  mailed,  advice  (DIC  CX1-CX4)  mailed 

*  SSR  AUTODIN,  technical  data  mailed. 

*  SSR  AUTODIN,  technical  data  TELEFAX: 

-  Digital 

-  Analog 

A.  Control  and  audit  trail  for  SSRs  and  technical  data  packages 

B.  Loss  rate  of  SSRs  and  technical  data. 

C.  Processing  ef f lclency/ef f ecti venes/ timeliness . 

D.  In-house  processing  procedures  required  to  accommodate  each 
alternative . 

E.  Identify  any  additional  resources  required. 

F.  Identify  problems  or  delays  encountered  in  the  collection/ 
transmittal  of  SSRs  and  technical  data. 

II.  For  SPCC  and  SMALC  only: 

A.  Did  the  use  of  a  electronic  device  to  send  technical  data 
improve  the  effectiveness  of  the  system? 

B.  Has  the  equipment  used  in  the  test  satisfactory  in  terms 
of  timeliness  and  quality? 

C.  Is  the  concept  of  using  electronic  devices  to  send  tech¬ 
nical  data  valid? 

D.  If  AUTODIN  was  used  to  submit  SSRs  would  a  means  to  sub¬ 
mit  technical  data  electronically  be  required? 

III.  Comments: 

Additional  comments,  recommendations,  conclusions  on  the  utility 
of  these  alternatives  for  Condition  1,  2,  or  3  SSRs. 

Attachment  B 
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AUTODIN  TEST  EVALUATION  GUIDELIHES 
(  SSR  receiver!) 

I.  Please  rank  and  evaluate  the  following  alternatives  (*)  as 
applicable  to  your  activity,  for  each  area  (A-F)  Identified 
below.  Specify  by  SSR  condition,  i.e..  Condition  1,  2,  or  3, 
where  possible. 

Alternatives : 

*  SSR  mailed,  technical  data  mailed,  AUTODIN  reply  (DIC  CX1-CX4) 

*  SSR  mailed,  technical  data  mailed,  advice  (DIC  CX1-CX4) 

*  SSR  AUTODIN,  technical  data  mailed. 

*  SSR  AUTODIN,  technical  data  TELEFAX 

-  Digital 

-  Analog 

A.  Control  and  audit  trail  for  SSRs  and  technical  data  packages. 

B.  Lo 88  rate  of  SSRs  and  technical  data. 

C.  Processing  ef f iciency/ef f ectiveness/timeliness . 

D.  In-house  processing  procedures  required  to  accommodate 
each  alternative. 

E.  Identify  any  additional  resources  required. 

F.  Identify  problems  or  delays  encountered  in  the 
collection/transmittal  of  SSRs  and  technical  data. 

II.  TELEFAX  of  technical  data 

A.  What  impact  did  the  use  of  electronic  equipment  to  trans¬ 
mit  technical  data  have  on  the  timeliness  of  technical  data  sub¬ 
mission? 

B.  Compared  to  the  system  of  having  technical  data  mailed, 
was  more  or  less  technical  data  received  using  telefax? 

C.  Was  the  quality  of  technical  data  received  via  electronic 
transmission  sufficient  for  DGSC  usage  in: 

1.  Item  Entry  Control 

2.  Item  Identification 
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4.  Entry  into  technical  data  library 

D.  For  SSRs  which  indicated  technical  data  was  required, 
was  that  data  received? 

E.  Were  technical  data  packages  received  that  could  not  be 
matched  to  SSRs  or  their  resubmittals? 

F.  Were  submitters  responsive  to  mechanical  followup  re¬ 
questing  technical  data? 

III.  A.  Additional  comments,  recommendations,  conclusions  on 
the  utility  of  the  alternatives  for  Condition  1,  2,  and  3  SSRs. 

B.  Do  you  feel  the  use  of  AUTODIN  and/or  TELEFAX  transmis¬ 
sion  of  technical  data  improve  the  effectiveness/efficiency  of 
the  following  actions: 

1.  Transmission  time 

2.  Internal  processing  time 

3.  Validation 

4.  Item  entry  control 

5.  NSN  assignment 

6.  Initial  advice 

7 .  Fina  1 

8.  Followups / re  pi ies 

9.  Control 
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VALIDATION  ERROR  CODES 


ARMY  VALIDATION  REJECT  CODES 


ATC  DEFINITION 

51  Invalid  Action  Taken  Code 

52  Invalid  Additional  User 

53  Invalid  Authorized  II  Data  Collaborator  Code 

54  Invalid  Authorized  II  Data  Receiver  Code 

55  Invalid  Acquisition  Advice  Code 

56  Invalid  Card  Number 

57  Invalid  Contract/Control  Number 

58  Invalid  Destination  Activity  Code 

59  Invalid  Date  NSN  Required 

01  Part  Number  and/or  FSCM  is  missing  or  does  not 

reflect  ail  the  required  digits  characters  to 
completely  identify  the  item  of  supply. 

04  Unit  of  Issue  is  invalid,  blank,  or  different 

from  established  Unit  of  Issue  for  currently 
managed  IMM  NSN. 

05  CIMM  to  SICC.  Item  submitted  is  blank  in  cc  30 

with  no  user  from  the  submitting  military 
service  (MILSVC)  recorded  in  DIDS  or  IMC  is 
other  than  Z. 

06  Invalid  percentage  of  end  item  east  code 

07  CIMM  to  SICC  only.  Item  submitted  on  SSR  does 

not  contain  a  unit  price  or  the  unit  price 
contains  other  than  numerics  and  is  not 
currently  managed  by  this  CIMM. 

18  Source  Code  of  LISSR  is  invalid 

23  Invalid  Retail  Quantity 

24  Invalid  Replenishment  Quantity 

25  Invalid  Retail  and  Replenishment  Quantity 

28  Non-numeric  NSN  entry 

31  Quantity  per  end  item  of  LISSR  contain  the  other 

than  four  numerics. 

38  Production  Lead  Time  (PLT)  is  blank  or  other  than 

numerics 

39  RNJC  is  other  than  blank  or  1  thru  7 

40  Invalid  Shelf-Life  Code 

43  Invalid  Demilitarization  Code 

47  Invalid  Date  of  Advice 

48  Invalid  Date  of  Request 

49  Invalid  Date  Repair  Parts  Required 

50  Invalid  Document  Identifier  Code 

51  Valid  PDSSR  with  no  LISSRs 

53  Invalid  End  Item  Delivery  Code 

54  Invalid  Document  Availability  Code 
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55 

Invalid 

date  technical  data  to  be  supplied 

59 

Invalid 

MOE  Rule 

61 

Invalid 

End  Item  Quantity 

65 

Invalid 

End  Item  Name,  Type  and  Model 

71 

Invalid 

End  Item  NSN 

72 

Invalid 

FSCM 

73 

Invalid 

Federal  Supply  Classification 

74 

Invalid 

Provisioning  Control  Code 

75 

Invalid 

Retail  Quantity 

76 

Invalid 

Replenishment  Quantity 

77 

Invalid 

Item  Management  Code 

78 

Invalid 

Item  Serial  Number 

79 

Invalid 

Unit  of  Issue 

80 

Invalid 

Interchangeability  Code 

81 

Invalid 

Special  Material  Content  Code 

82 

Invalid 

Materiel  Management  Aggregation  Code 

83 

Invalid 

Type  Change  Code 

84 

Invalid 

Technical  Data  Justification  Code 

85 

Invalid 

Reference  Number  Justification  Code 

86 

Invalid 

RNFC 

87 

Invalid 

RNCC 

88 

Invalid 

RNVC 

89 

Invalid 

Item  Name 

90 

Invalid 

Noun  Name 

91 

Invalid 

Manufacturers  Part  Number 

92 

Invalid 

NSN 

93 

Invalid 

Number  of  SSRs  Enclosed 

94 

Invalid 

Activity  Code  From 

95 

Invalid 

PSCN 

9L 
9M 
9N 
9  P 
9Q 
9R 
9S 
9T 
9U 
9V 


9X 

9D 

9E 

9F 

9G 


9H 


Invalid 

Invalid 

Invalid 

Invalid 

Invalid 

Invalid 

Invalid 


Method  Code 


East 


Procurement 
Source  Code 
Production  Lead  Time 
Percent  of  End  Items 
Weapon  System  Code 
Additional  User  Code 
Unit  Price 

Non-numeric  FSC/Support  Date  on  CXI/4 
Duplicate  Transaction 
Change  transaction  for  non-existent 
submission  transaction 
No  CXF  for  required  matching  CXB 
LISSR  not  accompained  by  a  PDSSR 
Card  1  or  Card  2  of  Part  Number  LISSR  missing 
Catalog  transaction  not  accompained  by  a  LISSR 
LISSR  TCC  equal  to  space  not  compatible  to  PDSSR 
equal  to  'P' 

with  TCC  equal  to  'R'  without  LISSR  with 
equal  to  'S'  or  LISSR  with  TCC  equal  to 


initial 


TCC 

LISSR 

TCC 

'S’ 


without  LISSR  with  TCC  equal  to  'R 
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9A  Valid  PDSSR  with  valid  and  invalid  LISSRs 

9B  Valid  PDSSR  with  invalid  LISSRs  only 

9C  Valid  catalog  transaction  with  invalid  LISSR 

NAVY  VALIDATION  REJECT  CODES 


ATC  DEFINITION 

A  Invalid  Production  Lead  Time 

B  Invalid  Unit  Price 

C  Invalid  NSN  or  Item  Name 

D  Invalid  PSCN 

E  Invalid  Contract/Control  Number 

F  Invalid  Item  Management  Code 

G  Invalid  FSCM 

H  Invalid  FSC 

I  Duplicate  Record 

J  Invalid  Document  Availability  Code 

K  Invalid  Reference  Number  Variation  Code 

L  Invalid  User  MOE  Rule 

M  Invalid  Supplemental  II  Data  Receiver  or 

Supplemental  II  Data  Collaborator 
N  Invalid  Manufacturers  Reference  Number 

P  Invalid  PCC 

Q  Invalid  End  Item  Quantity 

R  Invalid  ISN 

5  Invalid  Retail  Quantity 

T  Invalid  Replenishment  Quantity 

U  Invalid  DIC 

V  Multiple  errors  this  record 

W  Valid  PDSSR  with  no  valid  LISSRs 

X  Catalog  transaction  without  valid  LISSR 

0  Card  Number  1  or  Card  Number  2  for  Part  Number 

LISSR  missing 

1  Invalid  Activity  Code  To 

2  Valid  PDSSR  with  TCC  equal  to  'P'  without  LISSR 

having  TCC  equal  to  'C',  'D',  'R',  'S’,  or  'T1 

6  Invalid  Card  Number  on  Part  Number  LISSR 

8  Invalid  Date  of  Request 

AIR  FORCE  VALIDATION  REJECT  CODES 


CODE  DEFINITION 

00  Undefined  Error 

01  Invalid  Document  Identifier  Code 

02  Invalid  Provisioning  Control  Code 

03  Invalid  Date  of  Request 
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04 

Invalid 

Item  Serial  Number 

05 

Invalid 

Support  Date  in  CXI/4 

06 

Invalid 

AAC 

07 

Invalid 

Activity  Code  To  or  Activity  Code 

From 

09 

Invalid 

Action  Taken  Code 

10 

Invalid 

Contract/Control  Number 

12 

No  recor 

d  of  offer  for  this  CX2 

13 

Invalid 

Type  Change  Code 

14 

Invalid 

FSCM 

15 

Invalid 

Unit  Price 

17 

NSN/PSCN/Manufacturer  Part  Number  invalid 

on 

CXI/4 

18 

Invalid 

NSN 

19 

Invalid 

Date  of  Advice 

20 

Invalid 

End  Item  Quantity 

24 

LISSR  change  transaction  without  initial 

submission  LISSR  or  LISSR  with  TCC  equal 

•R' 

without  LISSR  with  TCC  equal  'S'  or  LISSR  with 
TCC  equal  'S'  without  LISSR  with  TCC  equal  'R' 

26 

Valid  LISSR  without  PDSSR 

28 

Invalid 

Replenishment  Quantity 

29 

Catalog 

transaction  without  LISSR  or  Card 

Number 

lorC 

ard  Number  2  of  Part  Number  LISSR 

missing 

31 

Invalid 

Demilitarization  Code 

34 

Invalid 

Technical  Data  Justification  Code 

35 

Invalid 

Quantity  Per  End  Item 

36 

Invalid 

Date  Technical  Data  to  be  Supplied 

38 

Invalid 

Unit  of  Issue 

39 

Manuf act 

urers  Part  Number  Missing 

40 

Invalid 

or  Missing  MOE  Rule 

41 

Invalid 

Retail  Quantity 

42 

Duplicat 

e  Item 

45 

Invalid 

Federal  Supply  Class 

51 

Invalid 

Weapons  System  Code 

52 

Invalid 

Materiel  Management  Aggregation  Code 

53 

Invalid 

Entry  in  Date  of  Request 

56 

Another 

transaction  with  the  same  PCC,  ISN 

,  DOR 

is  in 

error 

57 

Invalid 

Percent  End  Items  East 

58 

Invalid 

PSCN 

60 

Invalid 

Date  of  Advice 

GSA  VALIDATION  REJECT  CODES 


CODE  DEFINITION 

B300  Activity  Code  From  must  be  '75' 

B301  Must  be  blank 

B302  Type  Change  Code  must  be  'V'  or  space 

B303  Message  must  be  blank  or  say  "Deactive" 

B304  NSN  must  be  entered  when  ATC  is  YJ,  YR,  YU,  33,  34, 

YA,  or  YL 

B305  ADP  flag  must  be  blank  or  'N' 
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B306 

B307 


FSCN  must  be  entered  when  ATC  is  'YU* 

Item  Serisl  Number  must  be  alpha/numeric ,  no 

special  characters,  left- justified ,  no  embedded 
blanks . 

B308  DOR  must  be  numeric 

B309  DOA  must  be  numeric 

B310  Provisioning  Control  Code  must  be  alpha/numeric,  no 

special  characters 
B31 1  FSCM  must  be  blank 

B312  Invalid  Action  Taken  Code 

B313  Invalid  Activity  Code  To 

B314  Duplicate  submission  matching  PCC ,  DOR,  ACF 

B315  Date  is  optional  when  ATC  is  YQ,  YA,  or  YL  and  must 

be  numeric  when  entered 

B316  Date  must  be  entered  when  ATC  is  YX  or  YC  and  must 

be  numeric 

B317  FSCM  must  be  entered  when  ATC  is  YQ  and  must  be 

numeric 

B318  Message  must  be  "Deactive"  when  ATC  is  blank 

B319  Manufacturer  Part  Number  must  be  entered  when 

ATC  is  YQ 

B320  Activity  Code  From  must  be  alpha/numeric 

B322  Invalid  Activity  Code  From 

B325  Type  Change  Code  must  be  N,  P,  V 

B326  Number  of  SSRs  Enclosed  must  be  numeric 

B327  No  PDSSR  or  Multiple  PDSSRs 

B328  Number  of  different  ISNs  does  not  equal  Number 

of  SSRs  submitted  on  PDSSR 

B329  Transaction  does  not  match  SSR  Suspense  File 

IMM  MANUAL  VALIDATION  REJECT  CODES 


CODE  DEFINITION 

01  Invalid  Manufacturers  Reference  Number 

04  Invalid  Unit  of  Issue 

05  CIMM  to  SICC  only.  The  item,  submitted  is  blank 

in  cc  30  with  no  user  from  the  submitting 
MILSVC  recorded  in  DLSC  on  the  IMC  is  other 
than  Z. 

07  Invalid  Unit  Price 

18  Invalid  Source  Code 

23  Invalid  Retail  Quantity 

24  Invalid  Replenishment  Quantity 

25  Invalid  Retail  and  Replenishment  Quantity 

28  Invalid  NSN 

30  Invalid  Acquisition  Advice  Code 

31  Invalid  Quantity  Per  End  Item 

32  Package  error  for  LISSR  Transaction 

38  Invalid  Production  Leadtime 

39  RNJC  1 8  other  than  blank  or  numeric  1  thru  7 

40  Invalid  Shelf  Life  Code 
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52 

56 

59 

DODSSR 


CODE 

01 

04 

07 

18 

23 

24 

25 
28 

30 

31 

32 
3A 
3B 

3C 

3D 

3E 
3F 
3G 
3H 
31 
3  J 
3K 
3L 
3M 

3N 

30 

3P 

3Q 


3R 

3  S 
3Z 
36 
38 
40 


PCC  package  error  for  PDSSR 

Invalid  or  missing  data  on  a  CX2  record 

WIMM  to  SICC  only.  Missing  or  invalid  MOE  Rule 

VALIDATION  ATCs 


DEFINITION 


Invalid 
Invalid 
Invalid 
Invalid 
Invalid 
Invalid 
Invalid 
Invalid 
Invalid 
Invalid 
Package 
Invalid 
TCC  or 
space 
TCC  on 


Manufacturers  Reference  Number 

Unit  of  Issue 

Unit  Price 

Source  Code 

Retail  Quantity 

Replenishment  Quantity 

Retail  and  Replenishment  Quantity 

NSN 

Acquisition  Advice  Code 
Quantity  Per  End  Item 
error  for  LISSR  Transaction 
Activity  Code  To  on  LISSR 


PDSSR 

equal 

•N\ 

TCC 

on  LISSR  not 

PDSSR 

equal 

’V’  . 

TCC 

on  LISSR  not 

equal 

equal 


t  y  " 


TCC  on  PDSSR  equal  'P' ,  TCC  on  LISSR  not  equal 
'C* ,  ’D' ,  ’R* ,  'S* ,  »T' 

Invalid  Date  of  Request  on  LISSR 
Invalid  Provisioning  Control  Code  on  LISSR 
Invalid  Activity  Code  From  on  LISSR 
Invalid  PSCN 

Invalid  Item  Serial  Number 
Invalid  Card  Number 
Invalid  Item  Name 

Invalid  Federal  Supply  Classification 
Invalid  Additional  Activity  Code  on  Additional 
User  Transaction 
Invalid  Date  of  Advice 
Invalid  IMM  Manual  ATC 
ATC  '66'  on  Advice  Transaction 

ATC  equal  'YA',  'YL,  'YQ'  in  advice  or  follow-up 
response  transaction  and  support  date  not 
equal  spaces  or  valid  date 
ATC  equal  ’YX'  In  advice  or  follow-up  response 
transaction  and  support  date  not  valid 
Invalid  ATC  in  offer  reply  transaction 
Invalid  Procurement  Method  Code 
Duplicate  PDSSR  Transactions 
Invalid  Production  Leadtime 
Invalid  Shelf  Life  Code 
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42 

43 

51 

52 
5  A 
5B 
5C 
5D 
5E 
5F 
5G 
5H 
51 
5  J 
5K 


Duplicate  LISSR,  Catalog  or  LIAC  transaction 
Invalid  Demilitarization  Code 
Valid  PDSSR  with  no  LISSR 


PCC  package  error  for  PDSSR 

Invalid  Activity  Code  To  on  PDSSR 

Invalid  TCC  on  PDSSR 

Invalid  End  Item  NSN,  Name,  etc 

Invalid  Date  Repair  Parts  Required 

Invalid  Contract  Control  Number 

Invalid  Date  of  Request  on  PDSSR 

Invalid  End  Item  Delivery  Code 

Invalid  Provisioning  Control  Code  on  PDSSR 

Invalid  Activity  Code  From  on  PDSSR 

Invalid  End  Item  Quantity 

Invalid  Percent  End  Items  East 
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